0-6 technológia : 076 marketing 






kal hatz.bobal tab P 
E5.KE BBB BB 
t.! 5ttsk b-t E-t E 








ISSN 25845185 
! l j 
GET 518005 


86 









2004. március 





jzl-eili 

















Vifeetsreli 





Webcírr 





E-mail: 


technetmagazinEmicrosoft.hu 














y Tamás marketingigazgató 





joft.com/hun/technet/ 


Mit jelent 
a VVindovws XRF 
,Reloaded"? 


im Allchin, a Microsoft Plat- 

forms Group elnökhelyettesé- 

nek egyik nyilatkozatában 
hangzott el a Windows XP , Reloaded" 
kifejezés, ami azonnal lázba hozta az 
IT-vel foglalkozókat és számos téve- 
dés is szárnyra kelt, mint például, 
hogy a Windows XP ,Reloaded" új, 
önálló termék és a Windows ,Long- 
horn" megjelenését emiatt későbbre 
helyezték. Pedig dehogy... Érdemes a 
félreértéseket néhány mondatban tisz- 
tázni. 


A Windows XP Professional és Home 
Edition jelenleg is a Microsoft legnép- 
szerűbb termékei, melyekből 2003 
szeptemberéig több mint 130 millió 
példányt adtak el a világon. A Micro- 
soft a 2001-ben megjelent desktop 
operációs rendszert folyamatosan fej- 
leszti, új funkciókkal, összetevőkkel 
bővíti. 


A Microsoft a Windows ,Longhorn" 
2005-ben várható megjelenése előtt 
nem tervezi új vagy frissített desktop, 
például a köztudatban Windows XP 
Second Edition-ként élő operációs 
rendszer kiadását. A jelenleg folyó na- 
gyobb fejlesztések a Windows XP 
Media Center Edition-t, a Tablet PC 
Edition-t érintik, illetve a várhatóan 
nyár elején megjelenő Windows XP 
SP2 szervizcsomagot, melyek hama- 
rosan kibővítve, a hardvertechnoló- 
giák fejlődésének követésére ismét 
piacra kerülnek. E fejlesztések nem 
érintik a Windows XP operációs rend- 
szer magját. 

A Windows ,Longhorn" fejlesztése a 
Windows XP-től függetlenül, a legma- 
gasabb prioritással zajlik, melyeket 
nem befolyásol a Windows XP SP2 
vagy más, a Windows XP-vel kapcso- 
latos munkálat. A Windows ,Long- 


vi 


o0 a. 64 


horn" hivatalos béta verziójának meg- 
jelenése 2004 végén várható. 

A ,Reloaded" kifejezés a cégen belüli, 
a Windows XP-t érintő fejlesztési pro- 
jekteket jelöli, melyek egyike sem új, 
önálló termékben, hanem funkcionális 
frissítésekben realizálódik majd. Most 
még ezek egyikéről sem állnak rendel- 
kezésre végleges információk, melye- 
ket a Microsoft bejelenthetne. A meg- 
jelenési formák az elmúlt években is 
sokfélék voltak és még a cégen belül 
sem született döntés, így fölösleges 
ezzel kapcsolatban találgatásokba 
bocsátkozni. Ugyancsak nem dőlt 
még el, hogy az új funkciók az SP1- 
hez hasonló módon integrálva lesz- 
nek-e az eladott Windows XP csoma- 
gokba, illetve az új számítógépekre 
gyárilag telepítik-e majd őket. Aho- 
gyan az sem biztos, hogy az újonnan 
fejlesztett technológiák egy csomag- 
ba tömörülnek-e vagy külön-külön 
lesznek hozzáférhetők. Eddig nem 
dőlt el az sem, hogy az újdonságokat 
meg kell-e vásárolniuk a felhasználók- 
nak vagy ingyenes frissítésekként fér- 
hetnek hozzájuk. 


A jelenlegi legnagyobb és a legin- 
kább középpontban lévő fejlesztési 
projekt a Windows XP körül, a 2002- 
ben kiadott Service Pack 1-hez (SP1) 
hasonló formában érkező Service 
Pack 2 (SP2). Az SP2-vel több új funk- 
cionális képesség lesz a Windows XP- 
ben, melyek többségükben a platform 
biztonságosabbá tételét fogják szol- 
gálni. A Windows XP , Reloaded" tech- 
nológiák fejlesztése az SP2 munkála- 
tait semmilyen módon nem befolyásol- 
ják. A Windows XP SP2 megjelenését 
még 2004 első felére tervezi a Micro- 
soft, és bármilyen, a ,Reloaded"-dal 
kapcsolatos aktivitás csak ezután vár- 
ható. 





BLiG tárosáz helyettünk" 
TÁRCSÁZÓ VÍRUS, AMELY A PÉNZTÁRCÁNKBAN LÉVŐ TARTALMAT TÖRLI 


A modemes internetkapcsolattal rendelkezőket országszerte új vírus 
tartja rettegésben, amely ráadásul közvetlenül a pénztárcákat érintve 
okoz eddig nem tapasztalt módon kárt a gyanútlan felhasználónak. 


Uzletiintelligencia-szoftverek 
MS SOL 2000 REPORTIÍNG SERVICES I. RÉSZ 


Az üzleti intelligencia minden vállalat 
életében nélkülözhetetlen, segítségével 
megalapozott döntéseket hozhatunk, 
amelyek sikeressé tesznek minket a pia- 
SZAKIK, vítzaseper con. Az üzleti intelligencia nem feltétlenül 
I meportProcessng ] gy igényel egy teljes OLAP-ot vagy adatbányá- 

tk E szatot, mint például az SOL Server 

ú . Analysis Services-re épülő megoldások, de 
eément minden üzletiintelligencia- negoldásnak van 
közös eleme: a jelentések (report-ok). 

















Output Formats 
(HTML, Excel, 
IFF, Custom) 


Felhasználói CGRO szerkesztés 


POLICY GYÁRTÁS EGYÉNI IGÉNYEK SZERINT 





Milyen lehetőségeink vannak, ha például egy 
saját fejlesztésű alkalmazás beállításait sze- zi 

retnénk globálisan szabályozni? Vagy csak egy 5 gi Vért Meszaá 
egyszerű registry-bejegyzés értékét kellene : 
elegánsan, könnyen egy bizonyos OLJ-ban talál- 
ható objektumokra nézve érvényessé tenni? 


] úm Cortegzáten 





Kiszolgálópark üzemeltetése l. rész 


A DROMEDÁR ISTÁLLÓJA 


A kiszolgálók telepítésével, használatával, hibajavításával kapcsolatban 
számtalan cikket olvastam. A kiszolgálók üzemeltetésével kapcsolatos in- 
formációkat ellenben igen nehéz összeszedi. Ez a cikksorozat ennek a 
hiánynak a pótlására született. 





vVindowvws szolgáltatások I. rész 


ALAPOK ÉS KEZELÉS 
— zalai 





A szolgáltatások kritikusan fontos szerepet töl- 
tenek be a Windows kiszolgáló és munkaállo- 

I más operációs rendszerek, sőt, az ezeken futó 
alkalmazások tekintetében is. Nem árt tehát 
tisztában lenni szerepükkel, működésükkel, 
feladataikkal és lehetőségeikkel. 


Ma] 











A VVindows csomagtelepítője 


AZ UPDATE.EXE REJTELMEI 


Az Update.exe kissé rejtőzködő életmódot folytat: gyakran használjuk, 
mégis csak ritkán találkozunk vele közvetlenül. Az általa végzett 
feladat fontossága miatt azonban megérdemli a nagyobb figyelmet. 


Ami a hivatalos Microsoft 
tanfolyamokból kimaradt... 


EXCHANGE 2000/ EXCHANGE SERVER 2003 





Sorozatot indítunk, olyan témákról, amelyek kima- 
radtak vagy nem kellő részletességgel szerepelnek 

a hivatalos Microsoft tanfolyami anyagokban. 
Elsőként az Exchange Server 2003-mal kapcsolatos 
érdekességeket írjuk le, de az itt leírtak többsége az 
Exchange 2000-re is érvényes. 


Exchange General] Emalládorosses ] — Exchange Advanced 
General] Member Managed By 














(MemberOf7T Diain ]/ Environment ] Sessions ] Remote control 
Terminal Services Profle COM ] Exchange General 


E-mal Addresses: Exchange Featurer Exchange Advanced 
General ] Address ] Account ] Profte ]  Telephones ] Organization 








Kirművelt emberfők, Microsoft 
minősítéssel 


AZ OKTATÁSI TÁMOGATÁSOK RENDSZERE 


A vezető informatikai cégek közül a Microsoft elsők között ismerte fel az 
informatikai termékekhez és technológiákhoz kapcsolódó tudásanyag 
rendszerezésében rejlő előnyöket. Ennek megfelelően alakította ki oktatá- 
si és minősítési koncepcióját, amely napjainkra a világon mindenhol elis- 
mert egységes rendszert alkot és a keretében képzett, minősített szak- 

mberek is keresettek és megbecsültek a hazai és nemzetközi munkaerő- 
piacon egyaránt. Sorozatunkban a Microsoft kiforrott, de jelenleg is fejlő- 
dő oktatási rendszerét mutatjuk be. 


Közhírré tétetik... 


JELSZÓ-CSATA 


A Microsoft állásfoglalása a Microsoft Office VVord dokumentumok 
jelszavaival kapcsolatban 


MICROSOFT OFFICE ViSIO 2003 - MAGYAR NYELVEN IS 


A Microsoft Office Visio 2003 februártól már 
magyar nyelvű változatban is megvásárolható, 


így összesen már 17 nyelven elérhető. 
Dr VVÁAtSDON 


A MAN-IN-THE-MIDDLE TÁMADÁS 


A Dr VVatson nem más, mint az a rovat, amelyből 2000-ben az egész 
TechNet magazin kifejlődött. Oda térek vissza most, ahonnan egész , írói 
munkásságormT" elindult: egy havilap hátsó fertályán, az érdekességek 
rovatban leírom, amivel éppen foglalkozom. Ma már azt mondanánk rá: 
BLOG. Első blogom azzal az emberrel foglalkozik, aki középen áll. (FŐTI MARCELL) 














KI Is tárcsaz 
helyettünk"? 


TÁRCSÁZÓ VÍRUS, AMELY A PÉNZTÁRCÁNKBAN LÉVŐ 


TARTÁLMÁAÁT TÖRLI 


A modemes internetkapcsolattal rendelkezőket 


országszerte új vírus tartja rettegésben, amely ráadásul 


közvetlenül a pénztárcákat érintve okoz eddig 


nem tapasztalt módon kárt a gyanútlan felhasználónak. 


z első meglepetések akkor érték az áldozatokat, 

amikor a legnagyobb hazai távközlési szolgáltató 

hirdetésén felbuzdulva hazasiettek, ahol az 
internet már igen alacsony percdíjért, minden további elő- 
fizetés nélkül várta őket, majd a boldog szörfözgetést kö- 
vető hónapban kézhez kapták a sokszor tízezer, néha sok- 
szor százezer forintról kiállított telefonszámlájukat. Ekkor 
derült ki, hogy a ravasz vírus következtében az alacsony 
percdíj többezer forintossá változott. 


A tárcsázó vírus" ugyanis az internetre modemmel kap- 
csolódó felhasználó telefonos kapcsolatát bontja, majd 
valamely távoli ország internetszolgáltatójához tárcsáz 
be, akinek révén a hozzáférés továbbra is fennáll, ám 
a nemzetközi telefonhívás magasabb díja miatt a magyar 
szolgáltató percdíjának sokszorosáért. A hazai távközlési 
társaság pedig a vele szerződéses kapcsolatban álló 
nemzetközi társaság által leszámlázott összeget kéri 
a mit sem sejtő áldozattól. A vírus ténykedését természe- 
tesen nem lehet észlelni és a védekezés egyetlen módja 
az, ha a nemzetközi telefonhívásokat letiltatjuk a szolgál- 
tatónál. 


A károsultak lehetőségei 

A kérdés az, hogy ha már bekövetkezett a baj és kézhez 
kaptuk az elrettentő összegű telefonszámlát, milyen jogi 
lehetőségünk marad, ki ellen léphetünk fel és hova fordul- 
hatunk? 


A károsultak elsődleges reakciója természetesen az, hogy 
a saját szolgáltatójuknál reklamálnak és tagadják meg a 
számla kiegyenlítését. Kérdés, hogy felel-e a távközlési 
társaság, amely a jelen jogviszonyban modemes kapcso- 
latban internethozzáférési szolgáltatást nyújt, azért mert 
az általa meghirdetettnél jóval magasabb percdíjakon ju- 
tott hozzá a felhasználó az internetkapcsolathoz? 

A helyzet sajátosságát az okozza, hogy a távközlési szol- 
gáltatóval kétféle szolgáltatói minőségben áll a felhasználó 
szerződéses kapcsolatban. Egyrészt, mint távközlési szol- 
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gáltatóval, aki a telefonvonal segítségével azt teszi lehető- 
vé, hogy valamely internetszolgáltatóval betárcsázásos 
módon kapcsolatba lépve a felhasználó internethoz- 
záférést vegyen igénybe, másrészt, mint ez utóbbi szolgál- 
tatás nyújtója. 

Addig, amíg a távközlési szolgáltatótól vette a felhasználó 
igénybe az internet hozzáférési szolgáltatást, mindkét mi- 
nőségben szolgáltatott, attól a pillanattól kezdve, amikor 
már a vírus ténykedése eredményeként a vonalat bontotta 
és újra tárcsázott, de ezúttal nemzetközi számot hívva más 
internetszolgáltatóval lépett kapcsolatba, már csak mint 
távközlési szolgáltató volt jelen. 


Különösebb jogászi okfejtés nélkül is nyilvánvaló, hogy 
nem lehet jogalapja annak, hogy a szolgáltatótól követel- 
jük a kárunk megtérítését. A távközlési társaság valóban 
azt nyújtotta, amit a szerződésben vállalt, és azon a perc- 
díjon biztosította az internethozzáférést, amit meghirdetett. 
Az emelt díj már más internetszolgáltatóval való kapcsolat- 
felvétel alapján került kiszámlázásra. Ekkor a felhasználó 
részére kiszámlázott díj a nemzetközi tarifa alapján a távol- 
sági hívás díjaként a telefonos kapcsolatot, és nem az 
internethozzáférés szolgáltatást tartalmazza. 


Mégis, kinek a felelőssége? 

Vajon terheli-e tájékoztatási kötelezettség a távközlési szol- 
gáltatót azzal kapcsolatban, ha már más, nemzetközi tá- 
volsági híváson keresztül veszi igénybe a felhasználó az 
internethozzáférést? Fel kell-e erre valamilyen módon hívni 
a felhasználó figyelmét? 


A válasz a kérdésre nemleges. Nincs semmilyen monitoro- 
zási kötelezettsége a távközlési szolgáltatónak arra, hogy 
ellenőrizze, hogy az internethozzáférés szolgáltatást a fel- 
használó tőle közvetlenül, más hazai szolgáltatótól, vagy a 
Föld másik oldalán lévő sosem hallott nevű ország szolgál- 
tatójától veszi-e igénybe. Ha ilyen jellegű figyelmeztetést 
reklamálunk, akkor ennek teljesíthetőségéhez arra lenne 
szükség, hogy a távközlési szolgáltató folyamatosan figye- 
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lemmel kísérje azt, hogy a saját telefonvonalunkon keresz- 
tül milyen számot hívunk. Ez pedig már a privát szíféránkba 
való nem kívánt mértékű beavatkozás veszélyét is magá- 
ban hordozná. 


A felhasználót ért jelentős kár megtérítéséért a hazai szol- 
gáltató tehát nem tehető felelőssé. A távoli országbeli 
internetszolgáltató sem felel pusztán azért, mert általa ju- 
tott valaki akaratán kívül internethozzáféréshez. Gondol- 
junk csak arra, hogy az a hazai mobil társaság, amelynek 
révén valaki az Egyesült Államokból lép hazai internet- 
szolgáltatójával kapcsolatba, ugyancsak jelentős összege- 
ket fog számlázni az ügyfélnek, ám a szolgáltatás igénybe- 
vétele megtörtént, és azt mind a távközlési, mind az 
internethozzáférés-szolgáltató a szerződésnek megfele- 
lően teljesítette. 


Jogi megoldások a gyakorlatban 

Valaki azonban a gyanútlan felhasználót megkárosította. A 
vírus készítője nyilvánvalóan felelősségre vonható. Mivel a 
vírus Magyarországon is aktív és itt okoz kárt, így a magyar 
büntetőjog alapján is felelősségre vonható a készítő. Felté- 
telezve, hogy a vírus készítője nem pusztán öncélú játék- 
ból hoz jelentős bevételt távoli országok különböző 
internethozzáférési vagy távközlési szolgáltatóinak, felme- 
rül annak gyanúja, hogy valakit a haszonszerzés célja ve- 
zérelt. Ez esetben pedig az Európa Tanács informatikai bű- 
nözésről szóló egyezményében foglaltak eredményeként a 
Magyarországon 2002. április 1-től hatályos büntető ren- 
delkezések alapján a Btk. 300/C.§ (3) bekezdése szerint a 
számítástechnikai rendszer, adatok elleni bűncselekmény 
elkövetése miatt vonható felelősségre, és a bekövetkezett 
kár nagyságától függően háromtól akár tíz évig terjedő 


A HIVATALOS MICROSOFT TANFOLYAMOK 
MELLETT KÍNÁLT EGYEDI TANFOLYAMAINK: 


börtönbüntetéssel is sújtható az elkövető. A büntetőjogi kö- 
vetkezményeken túl természetesen az okozott kár megtérí- 
tése is követelhető. 


Az elméletben megnyugtatónak tűnő jogi megoldás gya- 
korlati alkalmazhatósága azonban már korántsem ilyen 
biztató. Mivel nemzetközi térben kell keresni az elkövetőt, 
ezért itt a magyar bűnüldöző szerveknek a jogsegély-e- 
gyezmények keretében kell segítséget igénybe venniük, 
amely módszerek köztudottan lassan működnek. Az 
internet világában pedig leginkább éppen a jogszolgálta- 
tás lassúsága teszi lehetővé, hogy a jogellenes cselekmé- 
nyek felderítetlenek és büntetlenek maradhassanak. Az az 
internethozzáférési vagy távközlési szolgáltató pedig, 
amely bevételeit ily módon gyarapította, addigra már rég 
köddé válik, amíg a bűnüldözés marka olyan szorosan 
megfogná, hogy a puszta logikai feltételezésen túl már a 
büntetőeljárás megindítására okot adó alapos gyanú is 
megfogalmazható lenne. 


Méltányosságban bízva 

A károsult felhasználó számára tehát nem sok a remény ar- 
ra, hogy kára megtérítésére bármilyen módja lenne. Az 
egyedüli, amiben bízhat, hogy a felhasználó akaratán kívül 
igénybe vett szolgáltatás díjából valamilyen módon ugyan- 
csak részesedő hazai távközlési szolgáltató méltányosság- 
ból, a saját hasznáról lemondva a számla megfizetésének 
egy részét elengedi a pórul járt ügyfelének. 


DR. MAYER ERIKA 
ügyvéd 
erikagodrinayer.ba 


IOSOFT- John Bryce 
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IOSOFT - JOHN BRYCE 
OKTATÓKÖZPONT KFT. 


"3 Rendszerbevezetési ismeretek (módszertan és gyakorlat) — 3 nap Cím: 1135 Buday 


Web: u 


9 Exchange Server 2003 rendszergazda ismeretek Exchange 2000 


rendszergazdáknak — 2 nap 


3 Visual Basic.NET Masters" Track: haladóknak — 5 nap 


Tanfolyamok az ország egész területén! 


Mobil oktatólaborunkkal bárhol megtartjuk tanfolyamainkat. 


(A mobil oktatólabor felállítását a Foglalkoztatáspolitikai és Munkaügyi Minisztérium támogatta.) 


Microsoft SA oktatási kuponok beválthatók 


Nálunk beválthatja a Microsoft Software Assurance licenc vásárlása után kapott 
oktatási kuponjait! Minden kupon ! ingyenes tanfolyami napot jelent. 


CERTIFIED Learning Solutions 


Ha nem tudja, hogy mi ez a kupon, hívja munkatársainkat! artner 











ÜUzletiintelligencia- 


szoftverek 


MS SOL 2000 REPORTING SERVICES 


Az üzleti intelligencia minden vállalat életében nélkülözhe- 


tetlen, segítségével megalapozott döntéseket 


hozhatunk, amelyek sikeressé tesznek minket a piacon. 


Az üzleti intelligencia nem feltétlenül igényel egy 


teljes OLAP-ot vagy adatbányászatot, mint például 


az SOL Server Analysis Services-re épülő megoldások, 


de minden üzletiintelligencia-megoldásnak van 


közös eleme: a jelentések (report-ok)]. 


Előzmények 

A Microsoft 2003 januárjától elhatározta, hogy a már meg- 
lévő SOL Server 2000 adatbázisplatformot kiegészíti és ez- 
zel egyedülállóvá teszi a piacon, azaz a meglévő OLTP 
(OnLine Transaction Processing) és OLAP (OnLine 
Analytical Processing) szolgáltatásokat tovább kombinálja 
a Reporting Services-sel is, amellyel egy teljes és integrált 
jelentéskészítő és adatanalizáló megoldást nyújt a fejlesz- 
tők számára egyetlen dobozban. 2003 végére a fejlesztő- 
csapatnak sikerült befejeznie a terméket, amely 2004 ja- 
nuár végétől már hozzáférhető. 


Telepítés, verziók 

Jó hír, hogy letölthető egy teljes értékű 120 napos próba- 
verzió [1], mellyel mindenki kipróbálhatja a terméket. A mi- 
nimális hardver- és szoftverkövetelményekről is itt [2] lehet 
tájékozódni. Amit még érdemes megemlíteni, hogy a ter- 
mék licencpolitikája teljes mértékben beépül az SOL 
Server licencekbe, azaz amennyiben ügyfelünk már ren- 
delkezik valamelyik SOL Server verzióval (Standard vagy 
Enterprise), minden további díj nélkül használatba veheti a 
jelentéskészítő szolgáltatást is. Ebből következik egy rossz 
hír, miszerint az MSDE (Microsoft Desktop Engine) nem tar- 
tozik a fenti verziók közé, sajnos MSDE-re nem támogatott 
a termék. A Reporting Services háromféle változatban kap- 
ható: Developer, Standard és Enterprise. Ez utóbbi támo- 
gatja a webfarm konfigurációt, a 4 fölötti CPU-t, a 2 GB fe- 
letti RAM-ot, a biztonságot kiterjesztő API-kat az egyedi 
autentikáció és autorizáció fejlesztéshez, valamint az adat- 
vezérelt előfizetések lehetőségét is. 


Bevezetés 


A Reporting Services egy új webalapú jelentéskészítő plat- 
form, amelynek segítségével készíthetőek és menedzsel- 


hetőek táblázatos, mátrix, grafikus és úgynevezett , free- 
form" jelentések, amelyek adatokat jelenítenek meg relá- 
ciós és többdimenziós (MDX) adatforrásokból., 


A Reporting Services teljes körű szolgáltatást nyújt (eszkö- 
Zök, API-k), de nem kell feltétlenül programozónak lennünk 
ahhoz, hogy kihasználhassuk ezeket. Használhatjuk ezen 
alkalmazásokat a jelentések megalkotásához, publikálásá- 
hoz, menedzseléséhez. A jelentés életciklusának minden 
fázisához létezik egy eszköz vagy alkalmazás, amit fel- 
használhatunk. Azoknak, akik programokat készítenek, 
rendelkezésre áll egy API a jelentéskészítés képességei- 
nek kiterjesztéséhez, saját alkalmazásaikba történő integ- 
rálásához. 


A webalapú jelentéskészítés előnyei 
A jelentéskészítő környezet felépíthető a meglévő adatbá- 
zis szerver (MS SOL Server) és webszerver (//S) infrastruk- 
túrára. A Reporting Services egy középső rétegbéli szer- 
vert biztosít, amely IIS alatt fut. Bármilyen jelentés elkészít- 
hető, amely adatokat jelenít meg az adatbázis szervereink- 
ből, bármilyen adatforrásból, amelynek létezik .NET 
,managed data provider"-e, OLEDB provider-e vagy 
ODBC adatforrása. 


A felhasználók — akik már jelentős webnavigációs ismere- 
tekre tettek szert — hozzáférhetnek a jelentésekhez és me- 
nedzsment eszközökhöz az általános célú webböngésző 
használatával. A jelentések egy központi tárolóból érhetők 
el, amely egy könyvtárstruktúraként jelenik meg. Készíthe- 
tő olyan jelentéskörnyezet, amely egy könyvtárhierarchiá- 
ba összegyűjti és rendezi a jelentéseket, valamint a hozzá 
tartozó egyéb tartalmakat, amelyet magunk alakíthatunk ki. 
A navigáció, a keresés és az előfizetés segíti a felhaszná- 
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lókat a számukra szükséges jelentések megtalálásában, 
futtatásában. 

A jelentések megjeleníthetőek, exportálhatóak mind asz- 
tali, mind weborientált formátumokba. Készíthetünk egy 
sor olyan jelentést, amely ötvözi a webalapú jellemzők 
erősségét a hagyományos jelentéskészítéssel. Készíthető 
interaktív, táblázatos, vagy ,free-form" jelentés, amely ada- 
tokat nyer ki egy előre ütemezett időpontban, vagy amikor 
szükséges (on-demand), amikor a felhasználó rákattint és 
megnyitja az adott jelentést. A mátrixjelentések magas 
szintű áttekintést nyújtanak, amelyek az ún. ,lefúrásos" 
technikával, sokkal részletesebb adatokat szolgáltatnak. A 
paraméterezett jelentések arra használhatók, hogy szűrjük 
az adatokat futásidejű értékek alapján. A felhasználók vá- 
laszthatnak különféle megjelenítési formátumok közül, ex- 
portálhatják futásidőben a jelentéseket a kedvelt formá- 
tumba, hogy később az adatok felhasználhatóvá váljanak 
máshol, vagy éppen kinyomtathatóak legyenek. 


Miért éppen szerver alapú jelentés- 
készítés? 

A szerver alapú jelentéskészítés út a központosított jelen- 
téstárolás és menedzsment felé, kialakíthatóak házirendek, 
biztonságos hozzáférések a jelentésekhez és a könyvtá- 
rakhoz, irányítható, hogyan legyenek a jelentések feldol- 
gozva és elosztva, szabványosítható a jelentések haszná- 
lata a vállalaton belül. 


A platformról 

A Reporting Services moduláris felépítésű. A platform a 
Report Server Engine-en alapul, amely feldolgozóból és 
szolgáltatóból áll, amelyek kinyerik és feldolgozzák az 
adatokat. A feldolgozás több komponensen oszlik meg, 
amely kiterjeszthető vagy integrálható a saját alkalmazá- 
sunkba. A megjelenítés azután történik, miután az adat ki- 
nyerésre került és leválasztódott az adatfeldolgozásról. Ez 
a jellegzetesség teszi lehetővé, hogy több felhasználó te- 
kintse meg ugyanazt a jelentést párhuzamosan egymástól 
eltérő formátumban, illetve 1-1 felhasználó gyorsan meg 
tudja változtatni a jelentés formátumát. Egy kattintásra a 
HTML-ből PDF, Excel, vagy éppen XML formátumot tu- 
dunk kiválasztani. 

Az architektúra úgy lett megtervezve, hogy támogassa az 
újfajta adatforrásokat és kimeneti formátumokat is. A kime- 
neti formátumok - amelyek be lettek építve a Reporting 
Services-be - felhasználhatóak a jelentések HTML-ben és 
egyéb formátumban történő megjelenítéséhez, más aszta- 
li alkalmazásokba való exportáláshoz, mint pl. a PDF, 
Excel, stb., de a fejlesztők készíthetnek saját megjelenített 
formátumot is, hogy kihasználhassák a nyomtató előnyeit 
vagy az eszköz képességeit. 

A fejlesztők be tudják építeni a jelentéskészítést a saját al- 
kalmazásaikba, vagy kiterjeszthetik a jelentést egyedi jel- 
lemzőkkel. Egy API - amely webszolgáltatásként áll ren- 
delkezésre - lehetőséget ad a SOAP és az URL végpon- 
tok által a könnyű integrációra a meglévő és új alkalmazá- 
sainkhoz, portáljainkhoz. 
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Delivery Channels 
(E-mail, SharePoint, 
Custom) 


Report Server Database 


A Reporting Services platform 


A telepítés utáni állapot 

Miután feltelepítettük a Reporting Services-t, elkészült az 
IIS szerverünkön két .NET alapú webalkalmazás: 
ReportServer és Reports névvel. Az előbbi maga a jelentés 
szerver, alatta megtalálhatjuk a ReportService.asmx fájlt, 
amely leírja azt a 93 darab webmetódust, amelyet a Re- 
porting Server webszolgáltatás nyújt. Az utóbbi pedig egy 
Report Manager ASP.NET alkalmazás, amelynek a segítsé- 
gével böngészőn keresztül futtathatjuk, illetve menedzsel- 
hetjük a már elkészült és publikált jelentéseinket. Létrejön 
egy ReportServer nevű Windows service is, amelynek a 
feladata a jelentések menedzselése, végrehajtása, üteme- 
zése, kézbesítése. Mindezeken felül a telepítéskor 
megadott SOL szerverünkön létrejött két új adatbázis: 
ReportServer és ReportServerTempDB. Ezenfelül egy pél- 
da adatbázis is keletkezett, ha ezt kiválasztottuk, 
AdventureWorks2000 néven. A fenti adatbázisokban törté- 
nik a jelentések és azok metainformációinak a tárolása, a 
biztonsági és házirend beállítások, a jelentések könyvtár- 
struktúrái, a felhasználók és azok hozzáférési jogosultsá- 
gai, cache, pillanatfelvételek, erőforrások, stb. A Start me- 
nüben pedig megtalálható a Microsoft SOL Server csoport 
alatt az Analysis Services, English Ouery, stb. alkalmazá- 
sokhoz hasonló módon a Reporting Services mappa is. 
Ebben található az SOL Server Books Online-hoz hasonló 
Reporting Services Books Online is, ami egy elég részletes 
súgó a termékhez, egy URL link a Report Manager-hez, va- 
lamint egy példakönyvtárra mutató link is. 


a End 
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Életciklus diagram 


A jelentés életciklusa 


Jelentés definíció 

Ebben a fázisban történik a jelentés tartalmának meghatá- 
rozása (adatok, képek, stb.), kifejezések és egyéb kalkulált 
mezők definiálása, a jelentés kinézetének megtervezése. 
Mindezek leírása egy speciális, kötött sémájú és publikus 
XML alapú leíró nyelvvel történik (Reports Definition 
Language, ezentúl RDL). A sémát leíró dokumentumállo- 
mány (XSD) megtalálható a telepítő CD NVextrasíReport 
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Definitioni könyvtárában is. A jelentés elkészítéséhez a 
Visual Studio.NET-be beépítésre került egy Report 
Designer, itt tudjuk elkészíteni a jelentésünk vázát. A vá- 
lasztható project típusok kibővültek egy új típussal: 
Business Intelligence ProjectsiReport Project. 


New Project 


Broject Types: 


XI Visual Cs Projects 

XI Visual J8 Projects 
e) CI Visual C4-4 Projects 

C Setup and Deployment Projects 
a CI Other Projects 

CI Visual studio Solutions 


Report Project Report Project. 
Wizard 


[ €reate a new report project using Report Wizard. 
Name: Report Project 
Location: ca . Browse... 


Project will be created at C:(Report Project1. a d ső 
esszé] (Esz ezette [ET 


VS.NET New Project wizard 








Ez a project típus rengeteg Drag8.Drop (fogd és vida) jel- 
legű művelettel lett felvértezve, amivel , szinte" kódírás nél- 
kül összekattintható egy-egy jelentésűrlap. Szóra érdemes 
még az Access report-ok egy az egyben történő átemelé- 
se a Report projektünkbe. Ez a Report Designer környezet 
is tartalmaz feldolgozó és megjelenítő funkciót, aminek a 
segítségével a jelentésprojektünkben már tervezési időben 
megtekinthetőek a jelentési nézetek. 


A fázis főbb lépései: 

m Kapcsolódás az adatforráshoz 

mu Lekérdezések elkészítése, amelyek előállítják a szük- 
séges adatokat, ezen adatok előállítanak egy mező- 
listát, amelyet később drag8drop módszerrel el tu- 
dunk helyezni a jelentés űrlapján 

m Az űrlap elrendezésének kialakítása, táblázat, mátrix, 
diagram, egyéb jelentésvezérlő-elemek kiválasztása. 

m A mezőlisták elhelyezése az űrlapon 

mu Egyéb tulajdonságok beállítása, alapértelmezett ér- 
tékek, csoportosító funkciók megadása 


A fenti lépések szervertől független kliens oldali műveletek. 
Miután elértük a kívánt eredményt és elkészült a jelenté- 
sünk, publikálhatóvá válik a Report Server-be és csak 
azután válik általánosan használhatóvá. A Report Designer 
kimenete egy RDL kiterjesztésű állomány, amely a koráb- 
ban már említett sémájú XML állomány. 

A VS.NET projektünk egyik fordítási (build) opciója a ,Pro- 
duction" opció, amely elvégzi az elkészített jelentésünk 
publikálását a Report Server-ünkbe. Mindemellett a Report 
Manager is rendelkezik fájl szintű importálási funkcióval 
(, Upload file"). 


Jelentésmenedzsment 

A Reporting Services használatának egyik legfőbb előnye 
azon képességében rejlik, hogy egy központi helyről 
megoldott a jelentések és a hozzátartozó tételek menedzs- 
mentje (a tételek közé tartoznak maguk a jelentések, a 
könyvtárak, az adatforrások, az egyéb erőforrások). Ezek- 
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hez a tételekhez beállítható a biztonság, jó néhány tulaj- 
donság, és némelyik esetében ütemezett műveletek. Ké- 
szíthető általános használatra osztott erőforrás és osztott 
adatforrás is. Mindezek eléréséhez a korábban már emlí- 
tett Report Manager használható, amely egy általános 
webböngészőt használó ASP.NET-es alkalmazás. A 
http:/localhost/Reports URL alól érhető el. A végfelhaszná- 
lók és a szerveradminisztrátorok egyaránt tudják mene- 
dzselni a jelentéseket, csak eltérő mértékben (a végfel- 
használók egy személyes munkaterületen, a ,My Reports" 
alatti mappába tudják publikálni és menedzselni saját je- 
lentéseiket). Az adminisztrátor viszont beállíthat végfel- 
használói jellemzőket, mappákat, alapértelmezett értéke- 
ket, osztott objektumokat, osztott adatforrásokat, ütemezé- 
seket. A feladatok attól függően végezhetők el, hogy az 
adott felhasználónak van-e hozzá jogosultsága (pl. ha a 
felhasználónak nincs joga jelentést importálni a szerverbe, 
akkor ezt a feladatot nem tudja elvégezni). A jelentésme- 
nedzsment a következő feladatokat foglalja magában: 


m Apjelentések szervezése a megfelelő könyvtárstruktú- 
ra kialakításával. 

m Olyan jellemzők engedélyezése, mint a My Reports, 
vagy a jelentéstörténet, vagy éppen a jelentések e- 
mail-ben történő továbbítása, kézbesítése (a kézbe- 
sítésről később lesz még szó). 

m Osztott ütemezések és adatforrások létrehozása álta- 
lános felhasználásra. 


Address [E] http:/flocalhostfReportsPagesjFolder. aspxltemPathzyo2fSampk v.] ÉJ] Go ünk 
SOL Server Reporting Home I Mv Subscriptions I 
e: 3 Services Site Settings I Help 


vV Home 5 E SEEN TEzES ÉSE 
e eki rorts searchfor[ JI 
Contents 


SlNew Data Source € Upload File 
(B Product Catalog 


Adventure Works full product 
catalog with pictures. This 











? New Folder 


€ Adventureworks 


(3 company Sales 
Adventure Works sales by 


guarter and product category. 
This report illustrates the use of 
a matrix data region that 
provides drilldown from summary 
data into detail data by 
showing and hiding rows. This 


report illustrates the use of 
embedded images, database 
images, page breaks, page 
footers, tables, condítional 
formatting, and a document 
map. 


report also illustrates the use of (d Product Line Sales 


background images. 
(j Employee Sales Summary 


Adventure Works sales for an 
individual employee. This report 
includes Sales Comparison and 


Adventure Works top five sales 
people and stores. This report 
illustrates a dataset with 
gueries containing the TOP 
clause. It also illustrates the 


use of tables, charts, 
parameters, calculated fields, 
and drillthrouah links. 


Current Month Sales 
Comparison charts in addítion to 


Report Manager a böngészőben 


Jelentések elérése és kézbesítése 

A Reporting Services-ben két módszer áll rendelkezésre a 
jelentések eléréséhez és kézbesítéséhez: amint igény van 
rá, azaz amikor a felhasználó kiválasztja a kívánt jelentést 
egy jelentés megtekintő eszközből (pl. Report Manager), 
illetve előfizetés útján. Ilyenkor automatikusan generálódik 
és kézbesítődik a szerver által a jelentés a beállított hely- 
re (e-mail, webfolder, file share, SharePoint site, stb.). Ami- 
kor a felhasználó előfizet adott jelentésekre, értesítést kap 
az elkészültéről, vagy megkapja a jelentés másolatát pl. 
egy e-mailben történt előfizetés esetében. Az adminisztrá- 


tor készíthet adatvezérelt előfizetést is, pl. egy nagyobb 
és dinamikus számú csoport részére, ilyenkor a címzettek 
futásidőben kerülnek kiértékelésre, pl. egy alkalmazotta- 
kat leíró SOL tábla felhasználásával. A megjelenő jelentést 
a felhasználó más megjelenítési formátumban is megtud- 
ja tekinteni. 


sLinked" (csatolt) jelentések 

Ezek a jelentések már meglévő és a szerverbe publikált 
jelentéseket használnak fel inputként (az elkészült jelen- 
tés képes magáról továbbadni az adatforrását, az adatle- 
kérdezés eredményét és a jelentés elrendezést, , layout"), 
hogy bizonyos jellemzőket átállítva egy új jelentést para- 
méterezzenek be vele. Ilyen jellemző az adatforrás, a kez- 
deti, alapértelmezett paraméterek, biztonsági beállítások, 
valamint a könyvtárban elfoglalt hely. Erre jó példa lehet 
egy vállalat két eltérő részlege, amely hasonló jelentése- 
ket kell, hogy generáljon. Ilyenkor egy általános, nem 
részlegspecifikus jelentést publikálunk egy mappába, 
majd készítünk belőle két ,linked" jelentést, amelyben az 
adott részlegparaméter alapértelmezett értékét beállítjuk 
a megfelelőre (sőt, csak olvashatóvá tesszük, hogy a 
szomszéd részlegre nem tudják lehúzni). Majd átrakjuk 
abba a mappa struktúrába, amelyben az adott részleg 
dolgozik, átírjuk a jelentések neveit, leírásait, biztonsági 
beállításait, kik férhetnek hozzá, stb. Mindezt kizárólag a 
Report Manager eszközzel ki tudjuk kattintani. 


Jelentés pillanatfelvételek 
(Snapshot-ok) 

A pillanatfelvétel olyan jelentés, amely tartalmazza a jelen- 
tés elrendezést (layout) és a lekérdezés által visszakapott 
adatokat egy adott időpillanatban. Ezek ütemezés útján 
jönnek létre és tárolódnak el a Report Server-ben, nem úgy, 
mint amikor a felhasználó rákattint egy jelentésre és ez ak- 
kor meg is jelenik, amikor szükség van rá (on demana). Az 
elmentett pillanatfelvételek megtekinthetőek, ilyenkor a tá- 
rolt adatokat fogjuk visszakapni a tárolt elrendezésben, és 
ekkor kerül sor a kívánt megjelenítési formátum előállításá- 
ra. Mivel nincs eltárolva a megjelenítési formátum, csak az 
adat és az elrendezése, ezért ebben az állapotban igen- 
csak hordozható. Mindezeknek két célja van: segítségével 
úgynevezett jelentéstörténet készíthető, valamint ellenőriz- 
hető a jelentés feldolgozása. Mivel ezek a pillanatfelvételek 
ütemezetten menthetőek a Report Server-be, ezért követ- 
hető a jelentések változása időről időre. Mivel az adat és az 
elrendezés egyértelműen leírja az adott jelentés előfordu- 
lását (a megjelenítés nem kerül tárolásra), így bármilyen 
jellegű változás alapvetően különbözni fog az előző pél- 
dánytól. A másik felhasználási eset, amikor a jelentés olyan 
nagy méretű, hogy az elkészítési ideje is hosszú, vagy ami- 
kor azonos adatokat kell megjeleníteni különböző felhasz- 
nálónak és fontos az adatok összemérhetősége, azonos- 
sága. Változékony adatokkal, azonnali jelentésgenerálási 
módszerrel mindez nehéz feladat lenne egyik percről a 
másikra. Segítségével az egy időben elkészült különböző 
jelentések adatai összehasonlíthatóvá válnak. 


Paraméterezett jelentések 
A paraméterezett jelentések bemeneti értékeket használ- 
nak fel a jelentés elkészítéséhez vagy az adatok feldolgo- 


zásához. A paraméterezett jelentésekkel változtatható 
a jelentések kimenete azáltal, hogy a jelentésben szereplő 
változóhelyek értéket kapnak futásidőben. A paraméterek 
használhatóak a jelentésben szereplő adatok szűrésére, 
vagy éppen a jelentés elrendezését vezérelhetik azáltal, 
hogy bizonyos részleteket elrejtenek, vagy éppen felfednek 
a lapon. Megadhatók dinamikus paraméterek is, amelyek 
függnek egymástól, kiválasztható egy legördülő listából, pl. 
egy ország paraméter kiválasztás után egy mellette lévő 
lista a kiválasztott országnak megfelelő megyékkel töltődik 
fel. A paraméterek jól használhatóak , linked", csatolt jelen- 
tések esetében is, pl. olyan esetben, amikor az egyik jelen- 
tés megjeleníti a vállalat összes régiójával kapcsolatos 
adatait, majd egy ,linked" jelentés beállít egy adott régiót 
és ezzel dinamikusan leszűri a korábbi jelentés adatait. A 
beállítható paraméterekhez megadott alapértelmezett érté- 
kek eltárolhatóak a jelentéssel együtt, így nem kell futtatás- 
kor ezeket megadni (sőt le is tiltható a szerkesztésük a je- 
lentés szerzője, az adminisztrátor, a tartalommenedzser ál- 
tal, ilyenkor ezek a paraméterek nem láthatóak a képer- 
nyőn). Kétféle paramétert különböztetünk meg: 


m Lekérdezésparaméter, amely egy TSOL SELECT 
szintaktika része és az a célja, hogy adatot válasszon 
ki, szűrjön le. Az ilyen paraméter megadása kötelező, 
hiszen nélküle nem teljes a lekérdezés. 

m Olyan paraméter, amely a jelentés feldolgozása alatt 
kerül felhasználásra, az adatok különböző szem- 
szögből történő megjelenítése érdekében. 


Report Server ,Folder" névtér 

A Reporting Services Folder névtér egy hierarchia, amely 
előre definiált és felhasználó által definiált mappákat tartal- 
maz. A névtér egyedileg azonosítja a jelentéseket és a hoz- 
zá tartozó tételeket, amelyek a Report Server-ben tárolód- 
nak. Fogalmilag ez a mappahierarchia a Windows fájlrend- 
szerhez hasonló. A Reporting Services-ben a mappák vir- 
tuálisak, amelyeket a weben keresztül érünk el. Sem a 
mappa, sem a tartalma nem létezik a fájlrendszerben. Ehe- 
lyett ezek a Report Server-ben találhatóak meg, de mappá- 
nak és tételeknek látszódnak, amikor elérjük a Report 
Server-t a böngészőn vagy egy webalkalmazáson keresz- 
tül. Amikor kiválasztjuk, vagy megkeressük a jelentést, a 
mappaútvonalak a jelentés URL-ének részévé vállnak. Az 
előre definiált mappák a Reporting Server számára vannak 
fenntartva, nem mozgathatók át, nem törölhetők és nem át- 
nevezhetők. Ilyenek a mappagyökeret jelentő ,Home", 
vagy a ,My Reports", amennyiben ez engedélyezve van, 
ilyenkor a felhasználó ide van irányítva a MUsersi mappa 
alá, olyan mint a Windows-ban a ,My Documents", minden 
felhasználó nevének van egy al-mappája. A , Users" úgy- 
szintén egy ilyen fenntartott mappa. 


Biztonsági modell 

A Reporting Services szerep alapú biztonsági modellt 
használ a jelentések, mappák és egyéb tételek hozzáféré- 
sének szabályozásához. A modell hozzárendel egy adott 
felhasználót vagy csoportot egy adott szerephez és a 
szerep meghatározza, hogyan férhet egy adott jelentéshez 
vagy tételhez a hozzá tartozó felhasználó vagy csoport. A 
biztonsági modell a következő komponensekből áll: 
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mu Egy felhasználói vagy csoport fiók, amely hitelesített 
a Windows vagy más biztonsági hitelesítő mechaniz- 
mus által (lásd később). 

m Szerep definíciók, amelyek meghatároznak egy sor 
akciót és műveletet. 

mu Biztosítható tételek, amelyre a hozzáférést kell sza- 
bályozni (mappák, jelentések, erőforrások). 


A fenti elemek kombinációja nem más, mint a szerephoz- 
zárendelés. 

A Reporting Services nyújt egy authorizációs (meghatalma- 
zási) modellt, de nem tartalmaz authentikációs (hitelesítési) 
komponenst. Ahhoz, hogy az authorizáció szabályszerűen 
működjön a hálózati biztonsági rendszernek hitelesítenie 
kell a felhasználót vagy csoportot, aki hozzá akar férni a Re- 
port Server-hez. Ebben a verzióban az authentikációt a 
Windows operációs rendszer hajtja végre. 


Előre definiált szerepek 
mM Browser 

Content Manager 

Publisher 

My Reports 

System Administrator 

System User 


Az egyes szerepekhez tartozó taszkok, feladatok megte- 
kinthetőek a Report Manager-ben a HomeJSite Settings 
3Configure item-level role definitions valamint a Home 
2 Site Settings 2? Configure system-level role definitions út- 
vonalakon. A HomesSite Settings?2Configure site-wide 
security útvonalon pedig beállíthatóak a szerverhez hozzá- 
férő felhasználók, csoportok, ugyanitt szerepek is rendel- 
hetőek hozzá. Alapértelmezésben csak a BUILTINVAdmi- 
nistrators szerepel a listában, amely a System Ad- 
ministrator szerepben van. Az előre definiált szerepekhez 
tartozó feladatok megváltoztathatók. A beépített szerepe- 
ket általunk felvett újakkal lehet kiegészíteni. 


Előfizetés 

Az előfizetés egy állandó kérés a jelentés kézbesítésére 
egy meghatározott időre vagy egy eseményre való válasz- 
ként, amely során előáll a beállításoknak megfelelő jelen- 
tés. Az ,on-demand" (amikor igény van rá) jelentéshez 
szükség van egy speciális beavatkozásra minden eset- 
ben, amikor meg akarjuk tekinteni a jelentést. Ellentétben 
az előfizetések arra használhatók, hogy automatizáljuk a 
kézbesítést a legnaprakészebb jelentésekhez. A Reporting 
Services kétféle előfizetést támogat. Az egyik a standard, 
amely egy adott felhasználó által létrehozott, karbantartott 
előfizetés, a másik az adatvezérelt előfizetés, amely során 
az előfizetők listája és a kézbesítési opciók futásidőben ge- 
nerálódnak (gyakori az a példa, amikor egy cégnél az al- 
kalmazottak fluktuációját is figyelembe kell venni, emiatt 
létrehoznak egy alkalmazottak táblát, amelyből naponta fu- 
tásidőben kiolvashatóak az aktuális előfizetői adatok). Az 
adatvezérelt előfizetés elkészítése jártasságot igényel a le- 
kérdezések felépítésében, valamint a paraméterek hasz- 
nálatában. A Report Server adminisztrátorok tipikusan ilyen 
személyek, akik tudnak ilyen előfizetést készíteni, mene- 
dzselni. Amikor egy felhasználó beállít egy előfizetést, vá- 





lasztania kell a lehetséges kézbesítési módok közül. Jelen- 
leg két beépített mód közül lehet választani: e-mail és fájl 
megosztás. A fejlesztők persze készíthetnek további kiegé- 
szítő kézbesítési módokat. Az előfizetés a következő ré- 
szekből tevődik össze: 


m Apjelentés, amely képes felügyelet, beavatkozás nél- 
kül futni (ezek azok a jelentések, amelyek tárolt hite- 
lesítési információkat használnak (credentials), vagy 
egyáltalán nem használnak ilyet). 

mu A kézbesítési mód (pl. e-mail) és a hozzá tartozó 
beállítások (pl. a címzett e-mail címe). 

m Az előfizetés feldolgozási feltételei. Gyakran a jelen- 
tés futásának feltétele idő alapú (pl. minden héten 
kedden, délután 3 órakor). Mindemellett, ha a jelen- 
tés pillanatfelvételként fut, előírható, hogy az előfize- 
tés akkor fusson, amikor a pillanatfelvétel frissül. 

m A vparaméterek, amelyeket a jelentés futásakor fel kell 
használni (hiszen ezeket nem tudja beállítani senki az 
automatizmus folyamán, azaz az alapértelmezett ér- 
téket kell felhasználni). Természetesen ezek a para- 
méterek egyediek is lehetnek, minden egyes előfize- 
tőre nézve (pl. egy vezetőt a saját régiójának jelenté- 
se fogja érdekelni, egy másikat meg a másik régióé). 


A fenti adatok az adott jelentéssel együtt kerülnek eltáro- 
lásra a Report Server adatbázisában (az SOL Server-ünk 
ReportServer nevű adatbázisában). Az előfizetéseket nem 
lehetséges a jelentésektől elkülönítve kezelni, azok szoros 
kapcsolatban vannak a jelentésekkel. Az előfizetések nem 
tartalmazhatnak kiegészítő leírásokat, más saját szöveget, 
egyéb elemeket. Az előfizetés csak azokat a tételeket tar- 
talmazhatja, amelyek korábban fel lettek sorolva. 


A következő rész tartalmából 

A következő részben bővebben foglalkozunk a fejlesztési 
kérdésekkel, a Visual Studio-ba integrált Report Designer 
komponenssel. A különböző jelentésvezérlő elemekkel. A 
paraméterezés gyakorlatával. A megjelenítési formátum 
egyedi programozási lehetőségeivel, a jelentésfeldolgozás 
kiterjesztésével, valamint a kézbesítés egyedi megvalósítá- 
si módszerével. Szót ejtünk a saját magunk által készített 
jelentések telepítési kérdéseiről. 


Példaalkalmazások 

Addig is, aki ennyi információ után már kedvet kapott a 
próbaverzió letöltéséhez, kipróbálásához, ajánlom a pél- 
dák telepítését és azok áttanulmányozását. Ezek a példák 
a Wrogram Filesicrosoft SOL ServeMMSSOLMReporting 
ServicesiSamplesi! könyvtárba települnek. Ebben található 
egy Reports mappa, amelyben vannak az .RDL 
kiterjesztéső előre megírt jelentésfájlok. Itt van az adatfor- 
rásleíró XML állomány is (AdventureWorks.rds). Ugyan- 
csak ebben a mappában van egy VS.NET Solution is 
(SampleReports.sln), amelyet megnyitva megnézhetőek az 
elkészített jelentések a Report Designer-ben, valamint a 
,Production" build opciót választva rögtön publikálhatjuk is 
a Report Server alá ezeket a jelentéseket. Ha elakadtunk 
volna egy Readme.htm állomány is segít minket. A példák 
részben a telepített AdventureWorks2000 SOL adatbázis- 
ból válogatnak le, részben pedig az Analysis Services-el 


v 


települt FoodMart2000-es példa adatbázisban szereplő 
OLAP kockák dimenzióiból (Foodmart Sales.rdl). 

Ezen felül található még három példa VS.NET projekt for- 
ráskóddal (Ctt, VB) együtt a NISamplesvApplicationst könyv- 
tárban. 


El Edt View Hep 
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Az RSExplorer példaalkalmazás 


Az RSExplorer példaalkalmazás a Report Manager szol- 
gáltatásait szimulálja egy Windows Forms alkalmazáson 
keresztül a webszolgáltatás webmetódusait hívogatva. 


TUZBE 
Specify a search string for a report that you would like to render and click Search. 
Search by: Name v 


Search string: c Search 


Items found: 


jAdventure Works sales by guarter and 
product category. This report illustrates the 


Product Catalog 
Product Line Sales 


showing and hiding rows. This report also 


illustrates the use of background images. 


Path: 


/SampleReportsA/Company Sales 
Save Report Close 


Renderas: (FELTI 


MHTML 


A FindRenderSave példaalkalmazás 


A FindRenderSave példaalkalmazás szintén egy Windows 
Forms alkalmazás, amely jelentések megkeresését és 
adott formátumba való lementését mutatja be, szintén a 
webszolgáltatást felhasználva. 








ÉJ hítpz[focahostfwebapokcatonz webFormi -aspx 











Hónap: (December View Report 


Alkalmazott Neve: [José Saraiva 7 Y 









Find ( Next 


a 


s] Export 


et : ői mi a b 
december 2003 Sales Report 


José Saraiva 

















October 
November 
Deremher 


§ 
a 


A Report-Viewer webes vezérlőt felhasz- 
náló (a paraméter nevek Report Manager-ben 
történt módosítása jól látható) 


A ReportViewer webes vezérlő példaalkalmazás egy 
ASP.NET kontrol példa, amely felhasználható arra, hogy a 
jelentéseink megtekinthetők legyenek a saját weblapunkra 
integrálva a Report Manager-től függetlenül. 
Csupán két tulajdonságot kell hozzá beállítanunk: 

mu ReportPath 

m ServerUri 


ForeColr [/] 
B Behavior 
AccessKey 
! — Enabled True 
!  EnableviewS True 
Tablndex 0 
!  Toolrip 
] Visible True 
(B Data 
/  (DataBindinc 
ÍB General Report Parameters 
ReportPath /SampleReports/Employee Sales Summary 
Serverurl — http://localhost/ReportServer 
! http:/flocalhos Server?jSamp 
(B HTMLVIewer Commands 
/ Parameters Default 


ortsjErap 





Toolbar Default 
! Zoom 10090 
(B Layout 

Height 10090 


Width 10090 


A Reporting Services-ről bővebb információk, linkek a hon- 
lapon [3] találhatók. 


MÁTHÉ ZOLTÁN 
matbezabsi.bu 
MCSD, SOL Server MVP 





Felhasznált források: 
Reporting Services Books Online 
http:/ / tíinyuri.com/ys3e8 


A cikkben szereplő URL-ek: 
[1]. httpi//tinyurlcom/25bv5 

[2]. http;// www.microsoft.com/ sa[/ reporting productinfo/ sysregs.asp 
[3]. http;// www.microsoft.com/ sagl/ reporting default.asp 
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Felhasználói (SRFC) 
szerkesztés 


POLICY GYÁRTÁS EGYÉNI IGÉNYEK SZERINT 


Milyen lehetőségeink vannak, ha például egy saját 


fejlesztésű alkalmazás beállításait szeretnénk globálisan 


szabályozni? Vagy csak egy egyszerű registry-bejegyzés 


értékét kellene elegánsan, könnyen egy bizonyos 


OLJ-ban található objektumokra nézve érvényessé tenni? 


kérdés több szempontból is érdekes: legyen jól 

szabályozható, sokoldalú, egyszerű, könnyen át- 

látható, hatékony. Ritkán van olyan megoldás, 
amely a felsorolt követelményeknek egyszerre tesz eleget, 
de szerencsére vannak kivételek. Egyik ilyen, amikor saját 
szerkesztésű Group Policy Object-et, GPO-t hozunk létre 
és csatoljuk különféle Active Directory konténerekhez. 


Mikor hasznos egy saját GPRPO? 
Biztosan előfordult már, hogy egy registry-bejegyzést sze- 
rettünk volna elterjeszteni a céges domain-ba tartozó 
összes gépen. Amíg minden gépre egyformán érvényesí- 
teni kell és verzió szerint is kompatíbilis az adott registry 
változás, semmi gond. A login script-be ágyazott 


regedit /s akarmi.reg 


formájú parancs kiadásával ez szépen, csendben megold- 
ható. A gond ott kezdődik, ha nincs ilyen login-seript lehe- 
tőség vagy nem megfelelő ez a megoldás, mert csak egy 
login-sceript-tel rendelkező felhasználó belépésével aktivi- 
zálódik a beállítás. Probléma lehet még, ha nem kompatíbi- 
lis a registry-változtatás a domain összes gépének operá- 
ciós rendszerével, illetve ha nem az egész gépállományt 
szeretnénk egyszerre , fertőzni" vele. Milyen jó is lenne ilyen 
esetben, ha lehetne egy-egy OU-ra külön-külön is érvénye- 
síteni a beállításokat. Ez főleg akkor ésszerű igény, ha az 
Active Directory-ban már eleve ki van alakítva egy, a cégre 
jellemző OU- hierarchia. Ebben az esetben Computer vagy 
User oldalról is hatékonyan lenne megközelíthető, szabá- 
lyozható bármely saját készítésű beállítás is. 


Készítsünk saját policy-t! 


Mielőtt ennek nekiugranánk, nézzük meg közelebbről, 
hogy miként épül fel a GPO Editor-ban a két Policy ág. 


c 













PT AN KEST TT TT A 
(I Console Rogt FEE 








[EST TT TÁ ZÁSA 












— (ga Computer Configuration 

8 CI Software Settngs 

7. I Windows Settings 

4 (I Administrative Templates 
7 af User Corfiguration 

4 CI Software Settings 

7 CI Windows Settngs 

16 (JJ Adminietrattve Templates 





Name 


computer Configuration 
1user Configuration 


Select an tem to view its description. 





slaszzssászszalül 
A Etended A Standard [e 


A GPO Editor ismerős ,arca" 


Ebben eddig semmi újdonság nincs, viszont vegyük észre, 
hogy ha az Administrative Templates sorok egyikén 
jobbgombolunk az egérrel, megtalálhatjuk az Add/Remove 
Templates menüpontot is, amivel előre gyártott .adm file- 
okat adhatunk hozzá az alapértelmezettek csoportjához. 
Ebből kifolyólag természetesen az összes általunk készített 
beállítás is ezek alatt fog majd megjelenni, illetve ebben az 
alcsoportban hozhatunk létre új alcsoportot, vagy költöz- 
hetünk bele egy már meglévőbe. Mindenkinek a saját ízlé- 
se szerint. Érdemes persze követni a már megszokott for- 
mát és logikát, hogy ne legyen zsúfolt és átláthatatlan az 
Editor felülete. Akkor dolgoztunk jól, hogyha a szerkesztés 
után egy évvel is világos, hogy mi, hol, miért van úgy, 
ahogy az adott Policy beállításaiban látható. Egy, már -— a 
Netacademia Tudástárban - publikált megoldásomat mu- 
tatom be majd itt is példaként, mivel ez egy valós problé- 
mát orvosol és mert teljesen ,custom" Policy. A szerkesz- 
téshez használt vizuális fejlesztőeszköz egy igen bonyolult 
alkalmazás: notepad.exe a neve. Rögtön első lépésként el 
kell döntenünk, hogy a registry mely ágában szeretnénk 
kutakodni és ezzel szorosan összefügg az a kérdés is, 
hogy milyen , természetű" GPO-t készítünk. Az alapváltozat 
a Fully Manageable Policy, amiket a cikk további részében, 
az egyszerűség kedvéért, csak ,sima" policy-nak fogok 
nevezni. Ezek használatával a usernek nincs beleszólása a 
Policy hatásába, illetve annak érvényre jutása után sem ő, 
sem pedig egy általa futtatott alkalmazás nem tudja meg- 
változtatni a beállítási értékeit. Ez persze megkötést is hor- 
doz magában, mert többnyire így a , sima" policy-val csak 


nw 
o 
o 
B 
oO 


a gyári (Microsoft-os) jellemzőket és alkalmazásokat 
finomhangolhatjuk. Tehát a sima GPO-k az editor által kék 
színű ikonnal jelzett szabványos Policy objektumok. Ők kö- 
telezően az alábbi registry helyeken laknak: 
Bu HKLMSOftwarePolicies, vagy 
u HKLMSoftwareWicrosofüWindows! 
CurrentVersionPolicies 
Illetve a User ágban: 
u HKCUNSoftwareolicies, vagy 
u HKCUNSoftwareicrosofüWindows! 
CurrentVersionPolicies 


A másik változatot képviselik a már említett Preference jelle- 
gű GPO-k, amelyek tipikusan a nem Microsoft eredetű — 
vagy például a saját fejlesztésű — alkalmazások kontrollját 
végző GPO-kat jelentik. Ők kifejezetten nem az előbb felso- 
rolt registry helyeken dolgoznak, de pont ez az amiért sok 
esetben nagyon hasznosak tudnak lenni, mert szinte bármit 
elérhetünk velük. Ezek az említett tulajdonságaik miatt piros 
színnel jelennek meg az Editorban. Ráadásul ez így nem is 
egészen pontos meghatározás, hiszen magától ez a típus 
nem is jelenik meg, de a szűrők egyszerű kikapcsolásával 
ez megoldható. A Preference jelleg értelmezése pedig úgy 
szól, hogy ő ugyan beállít egy értéket az adott registry- 
kulcsban és ezt minden GP frissítéskor elvégzi, de ettől 
még azt a felhasználó illetve egy alkalmazás át tudja írni, 
meg tudja változtatni. Mindezt persze csak akkor, ha van jo- 
ga hozzá. Lássuk tehát, hogy miként épül fel egy egyszerű 
.adm template file. A könnyebb érthetőség kedvéért a pél- 
dát strukturáltan szerkesztettem meg, hogy a ,Visual 
Notepad"-ben is jól látszódjanak az összetartozó definíció- 
párok. Így néz ki a legegyszerűbb registry alapú Policy: 


CLASS MACHINE 

CATEGORY "Az en alkalmazasom" 
KEYNAME "aregistrykulcsWpontosVutvonala" 
POLICY "Az en policym" 
VALUENAME "A registry kulcs pontos neve" 
VALUEON 1 
VALUEOFF 0 
END POLICY 

END CATEGORY 


Az már első pillantásra is látható, hogy rögtön az elején el- 
dől, hogy a HKLM (class machine) vagy a HKCU (class 
user) ágban hatásos policy-ről van-e szó. Importáláskor ér- 
telemszerűen a megfelelő helyre kell majd behívni az 
Administrative Templates alcsoportok egyikébe. Az import 
folyamat részeként kapunk egy automatikus szintaxis-el- 
lenőrzést, aminek csak hiba esetén van látható kimenete. 
Ha valamit rosszul csináltunk, az Editor szűkszavúan jelzi, 
hogy mi nem tetszett neki. Azt pedig, hogy a Policy sima 
vagy Preference jellegű lesz-e, az dönti el, hogy a 
KEYNAME mezőben hova hivatkozunk. (Lásd a korábbi 
felsorolást.) Természetesen a hivatkozást a HKLM illetve a 
HKCU nélkül kell már írni, hiszen erről döntöttünk az elején 
a CLASS paranccsal. Vizsgáljuk meg azt a kiskaput, amit 
az előzőekben már említettem arra nézve, hogyha sima 
Policy-t szeretnénk létrehozni, de mindezt egy saját fejlesz- 
tésű alkalmazásunkhoz. Ebben az esetben az alkalmazás 
policy-val szabályozandó részeit kapcsolgató registry- 
bejegyzéseket az alapértelmezett registry ágakba kell ten- 
ni és az alkalmazást is úgy kell megírni, hogy onnan olvas- 


son majd beállítási értékeket. Így két legyet ütünk egy csa- 
pásra: nem kell majd filtereket állítgatni, hogy megjelenjen 
a Policy az editorban és nem is Preference lesz a beállítás 
jellege, hanem szigorú Policy. Példával demonstrálva ez 
így nézne ki: 


CLASS USER 

CATEGORY "enprogramom" 
KEYNAME "sofítwareWpoliciestsajatprogramom" 
POLICY "Az en programszabalyozo policym" 
VALUENAME "legyenkismenu" 
VALUEON 1 
VALUEOFF 0 
END POLICY 

END CATEGORY 


Ezek után, már csak úgy kell megírni az ,enprogramom"- 
at, hogy a kérdéses beállítás értékét a HKEY CURRENT 
USERWSoftwaretPoliciestsajatporogramom. ágban található 
,legyenkismenu" registry kulcsból olvassa ki. Ezek ismere- 
tében, innentől ki-ki maga döntheti el, hogy milyen policy-t 
és hova készít. Hab a tortán, hogy a két típus kombinálha- 
tó egymással, így installálás közben például létrejöhet egy 
Preference jelleg, amit később sima policy-val jobban be- 
szabályozhatunk. Fontos megjegyezni, hogy a sima Policy 
természetesen nem írja felül (nem tudja felülírni) a 
Preference típusú Policy által a registry más (nem 
alapértelmezett) ágaiban létrehozott értékeket! Ha valaki- 
nek ez már ,túl erős", még mindig ott a lehetőség az egy- 
szerű, registry alapú, Preference jellegű ,piros" Policy ké- 
szítésére. Lássuk, hogy ilyen esetben hogyan kell a filtere- 
ket kikapcsolni. Windows 2000 esetében az MMC konzol 
View menüjében a Show Policies Only elől kell leszedni a 
pipát. Windows 2003 vagy XP használatakor pedig az 
Administrative Templates, jobbgomb 2 View 2 Filtering 
menüpontban kell a legalsó pipa eltávolításával rávenni az 
Editort, hogy ne csak a Fully Manageable GPO-kat mutas- 
sa. Ilyenkor aztán szabadon , garázdálkodhatunk" a gyári 
és a sajátkészítésű Group Policy objektumok között. Sok- 
szor előfordul, hogy olyasmiket szeretnénk átírogatni a 
registry-ben, amihez az alkalmazásfejlesztők nem policy- 
barát módon készítették fel a programjaikat. Tehát nem az 
alapértelmezett sima policy-s registry ágakban vannak a 
számunkra érdekes beállítások. Mint azt látni fogjuk, ez 
igaz lehet egyes Microsoft-os alkalmazásokra is. Ilyenkor 
már nincs mit tenni, marad a Preference Policy. Az .adm 
file-ok hivatalos lakhelye a 9ewindir9etinf könyvtár. Ide te- 
gyük a sajátunkat is, mert az import során is ez az 
alapértelmezett forráskönyvtár. 


A Policy születése 

Vizsgáljunk meg tehát egy konkrét esetet, amikor is 
Preference jellegű policy-t kell készítenünk egy Microsoft-os 
szolgáltatáshoz. (Tesszük ezt azért, mert az előzőek isme- 
retében kiderítettük, hogy az alkalmazás policy-val szabá- 
lyozható részében nincs benne ami nekünk kell, de amúgy 
az általunk keresett beállítás, a registry más ágában azért 
megtalálható.) Mindenki ismeri a DNS Client nevű Service- 
t, ami a gép által használt DNS szerverrel való kommuniká- 
ciót hivatott dinamikusabbá tenni, a névfeloldásokra fordí- 
tott hálózati forgalom csökkentésével. Ezen képességének 
gyakorlása közben tesz olyasmit is, aminek gyakorlatilag 
nem mindig jó a következménye. Ez pedig a Negative 
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Caching. Magyarul, a DNS lekérdezésekre érkezett hibás, 
vagy hiányos válaszokat is eltárolja egy darabig, és amíg az 
ide vonatkozó TTL le nem jár, nem is kérdezi meg újra a 
DNS szervert. Konkrétan, ha egy adott időpillanatban ép- 
pen nem sikerült lekérdeznie egy DNS bejegyzést, mondjuk 
egy pillanatnyi hálózati kiesés miatt, máris halmozni kezdi a 
hibát az összes hasonló témájú lekérdezés esetében, ahe- 
lyett, hogy megpróbálná újra lekérdezni a DNS szervert. Va- 
jon van-e, akinek még nem kellett beírnia az 


ipconfig /flushdns 


parancsot? Ugye milyen unalmas ezt írogatni hibajavítás- 
kor, szinte már jó lenne, ha lenne rá egy rövid parancs. 
Még jobb lenne, ha ki lehetne kapcsolni ezt a funkciót, 
ráadásul mindezt egyszerre a domain összes gépén... A 
kérdéses registry kulcsok a HKLMisystemiCurrentCont- 
rolSeXServicesDnscachePParameters helyen kell, hogy 
megszülessenek, mert alapból nincsenek beírva. Neveik a 
következők: 


NegativeCacheTime 
NetFailureCacheTime 
NegativeSOACacheTime 
MaxCacheEntryTtlLimit 


Mindegyikük egész számot vehet fel, mint értéket és ezek 
másodpercben értendők. Az utolsó kulcs értéke hatással 
van az összes tárolt eredményre, az ebben beállított érték 
lesz a hivatalos Time To Live a lokális cache-ben. Egysze- 
rű, de hatásos trükk lehet, ha ezt 0-ra vesszük le, mert eb- 
ben az esetben gyakorlatilag nincs helyi cache, igaz, en- 
nek nem sok értelme lenne. Nézzük meg inkább, hogy 
policy-val, hogyan is lehet ezt szépen szabályozni. 


CLASS MACHINE 
CATEGORY "Network" 
CATEGORY "DNS Client" 
CATEGORY "Negative Cache Control" 
KEYNAME ! !keyname 
POLICY "Negative Cache Control" 
EXPLAIN ! ! explanation 
PART "Negative Cache Time:" 
NUMERIC 
VALUENAME "NegativeCacheTime" 
DEFAULT 0 MIN 0 MAX 900 SPIN 1 
REGNUIRED 
END PART 
PART "Network Failure Cache Time:" 
NUMERIC 
VALUENAME "NetFailureCacheTime" 
DEFAULT 0 MIN 0 MAX 900 SPIN 1 
REGUIRED 
END PART 
PART "Negative SOA Cache Time:" 
NUMERIC 
VALUENAME "NegativeSOACacheTime" 
DEFAULT 0 MIN 0 MAX 900 SPIN 1 
RERUIRED 
END PART 
PART " " TEXT END PART 
PART !!partname TEXT END PART 
PART "Maximum Cache Entry TTL Limit:" 
NUMERIC 
VALUENAME "MaxCacheEntryTtlLimit" 
DEFAULT 60 MIN 0 MAX 900 SPIN 1 
RERUIRED 
END PART 
END POLICY 
END CATEGORY 
END CATEGORY 
END CATEGORY 
Istrings] 





keyname-"systemtCurrentControlSetAServicesMDns 
cachelParameters" 


explanation-"This Policy is for controling 
the Negative Caching behaviour in the DNS 
Client service" 


partname-"The TTL Limit value is effective 
on all other cached entries!" 


Vegyük észre, hogy a strukturált szerkesztést elősegítendő, 
használhatunk egy [Strings] szakaszt, amiben hosszú ka- 
rakterláncokat definiálhatunk, és dupla felkiáltójellel hivat- 
kozhatunk rájuk a szükséges helyen a Policy szerkezeté- 
ben. A CATEGORY sorokban megadott értékekkel beköl- 
töztünk egy már meglévő fába, illetve a harmadik definíció- 
val pedig létrehoztunk egy , Negative Cache Control" nevű 
bejegyzést a DNS kliens gyári beállításai alá. A logika tehát: 
ami van, megmarad, ami nincs, létrejön. Bárhová büntetle- 
nül készíthetünk új alcsoportot, vagy új policy-t a többi kö- 
zé. Ha a filter nincs kikapcsolva és az új policy preference 
jellegű, csak az őt hordozó alcsoport neve látszik, maga a 
policy ,belseje" nem. A Group Policy Management Console 
használatával — letölthető az [1]-es címről — egyszerűbb a 
szerkesztés, átláthatóbb az egész domain policy struktúrá- 
ja, emellett a hozzárendelések is egyértelműbbé válnak. 
Ezenkívül nagyon hasznos, hogy az adott GPO-t vizsgálva 
a Settings fülön pontosan mutatja, hogy miket állítottunk be 
benne, természetesen a saját készítésűeket is. Itt nem függ 
a kijelzés semmilyen filtertől, a saját bejegyzések is remekül 
megférnek gyári társaikkal. 


A Policy szerkezeti felépítése 

Az előző példában látható, hogy egy más típusú értékadá- 
si formát használtam a registry kulcsokhoz, mint a korábbi 
példákban. Itt nem csak egyszerű ki/be kapcsolók vannak, 
hanem előre meghatározott és behatárolt értékválasztó s0- 
rok. Az összes - a gyári policy felületeken már megszokott 
- formát használhatjuk! Van legördülő menü, checkbox, 
szöveges mező, stb. Természetesen a registry kulcsok típu- 
sa is definiálható, és még sok egyéb más jellemző is. Hasz- 
nos lehet, ha fogunk egy gyári .adm file-t és a notepad-be 
betöltve ellessük belőle a jó megoldásokat, hasznos trükkö- 
ket. Egyszerű a nyelvezet, a Turbo Pascalon nevelkedett 
kollégáknak könnyebbséget jelenthet a szerkezeti hasonló- 
ság. (A pontosvesszőkre szerencsére már nincs szükség.) 
Mivel e cikk keretein belül csak a saját készítésű policy-val 
elérhető lehetőségek bemutatása volt a cél, az átfogó szin- 
taxis ismertetésétől itt eltekintek. Ezek részletes magyará- 
Zatát a Microsoft KB 225087 számú cikke tartalmazza, illet- 
ve az [2]-es címen elérhető MS GPO White Paper. Remélem 
sikerült felkeltenem a kedves olvasó érdeklődését, és a jö- 
vőben mindenki hasznos közreműködésével jobbnál jobb 
GPO template-ek lesznek elérhetők a neten. Ha valaki nem 
szeret gépelni, a példa korábbi verziója elérhető a [3]-as 
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[1]. http;//msdownload netacademia. net, info.asp?prid-1147 
[2]. http:Z/ www.microsoft.com/ windows2OOO,/ docs/ roppaper:doc 
[3]. http:// www.netacademia net, tudastar/ Default. asp?upid-1654 
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Kiszolgálópark 
üzemeltetése 


A DROMEDÁR ISTÁLLÓJA 


A kiszolgálók telepítésével, használatával, hibajavításával 


kapcsolatban számtalan cikket olvastam. 


A kiszolgálók üzemeltetésével kapcsolatos információkat 


ellenben igen nehéz összeszedni. 


Ez a cikksorozat ennek a hiánynak a pótlására született. 


ikksorozatunkban górcső alá kerülnek az üzemel- 

tetéssel kapcsolatos kérdések, az elhelyezéstől a 

napi munkákig bezárólag. Az első rész a fizikai el- 
helyezéssel, a kiszolgálóterem kialakításával foglalkozik. 


Alapinfrastruktúra 
A kiszolgálók elhelyezése ma Magyarországon általában 
sok kívánnivalót hagy maga után. Noha egyre több és egy- 
re értékesebb információt tárolunk kiszolgálóinkon, így 
ezek rendelkezésre állása egyre fontosabb. A cég napi üz- 
letmenete alapjaiban támaszkodik a 
szolgáltatások elérhetőségére, ezek a 
,fontos" kiszolgálók mégis sokszor 
igen mostoha körülmények között 
kénytelenek ellátni — általában 24 órás 
— munkájukat. 


Sok szervizes, rendszermérnök isme- 
rősömtől hallottam horrortörténeteket 
ilyen elhanyagolt kiszolgálók javításá- 
ról. A cégek, elsősorban a kisebb cé- 
gek, amelyeknek már éppen elég ter- 
het jelent magának az eszközparknak a beszerzése, a 
megfelelő üzemeltetéssel is jelentősen javíthatják a kiszol- 
gálók biztonságát, ha okosan, előre gondolkodnak és már 
a tervezés, kivitelezés során figyelembe veszik a környeze- 
ti feltételeket. 


Az ősdromedár barlangja 

A kiszolgálótermek egyidősek az első számítógépekkel, fő- 
leg, ha nem felejtjük el azt a tényt, hogy akkoriban egy-egy 
gép teljesen ki is töltötte a rendelkezésére álló igen terje- 
delmes géptermet. Ezek a géptermek sokféle gépészeti 
berendezéssel fel voltak szerelve, hogy az igen kényes be- 
rendezések számára a megfelelő környezetet biztosítani 
tudják. A magas fogyasztás és a speciális igények kielégi- 
tése érdekében az elektromos hálózatnak is speciális 
kialakításúnak kellett lennie. A kiszolgálókkal a kapcsolatot 
általában terminálok segítségével tartották, külön operátor 





helyiségekből. Ezek az igen érzékeny és drága gépek ál- 
talában nagyon fontos adatokkal dolgoztak, ezért speciális 
biztonsági intézkedésekkel, berendezésekkel, emberi erő- 
vel védték ezeket az objektumokat, naplózták a forgalmat. 
A bajok akkor kezdődtek, amikor a kis, házi gépek teljesít- 
ményben és tudásban elkezdték utolérni nagyobb , testvé- 
reiket". Egyre fontosabb és nagyobb teret kapott a minden- 
napi életben az informatika. Ekkor egyre több és egyre ki- 
sebb cég kezdett számítógépeket, kiszolgálókat beállítani 
az üzletmenetébe. Ezekhez a kiszolgálókhoz már nem járt 
külön épület, többnyire egyszerűbb 
feltételekkel is beérték. Aztán aho- 
gyan az üzletmenet egyre nagyobb 
mértékben támaszkodott a kiszolgálók 
megbízhatóságára, illetve egy-egy 
meghibásodás kihatása egyre na- 
gyobb volt az üzletmenetre, úgy érté- 
kelték át újra a környezet szerepét. 
Ekkor a kiszolgálók újra útra keltek, a 
környezet változott. 

Ma a legkorszerűbb kiszolgálótermek 
számos tekintetben hasonlítanak az 
első termekre, ez a beruházási és üzemeltetői költségekből 
is jelentős tételeket köt le. 

Törekedni lehet az ideális feltételek elérésére, azonban 
ezek kialakítása jelentős többletköltséget jelent. Az, hogy 
pontosan milyen kompromisszumokat kössünk egyedi 
megítélés kérdése. Ebben sokat segít a kockázatelemzési 
dokumentáció elkészítése, amiből kiderül, hogy melyik pa- 
raméternek milyen beruházási és üzemeltetési költségei 
vannak, illetve, hogy ezek elhagyása / megváltoztatása mi- 
lyen kockázatot jelent. 


A dromedár albérletben 

Azoknak, akiknek fontos a biztonságos üzemeltetés, ám 
nem éri meg, vagy nem képesek önerőből az igényeiknek 
megfelelő kiszolgálótermet üzemeltetni és fenntartani, cél- 
szerű a saját kiszolgálójukat egy központi kiszolgálóterem- 
ben elhelyezni (szerver hosting); a legkisebbeknek még 
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saját kiszolgálót sem kell venniük, számukra adott a lehe- 
tőség a teljes infrastruktúra bérlésére, illetve szolgáltatások 
használatára egy erre szakosodott szolgáltatónál. 


A tervezés 

A kiszolgálótermek tervezésére az irodaépület tervezésé- 
vel egyidőben kell sort keríteni. 

Érdemes az alábbi szempontokat figyelembe venni: 

m Milyen kiszolgálók kerülnek majd várhatóan ide? 
Ezeknek várhatóan milyen speciális igényeik vannak? 
Milyen közlekedési és szállítási igények merülnek fel? 
Mekkora és milyen redundanciájú erősáramú iígé- 
nyeknek kell megfelelni? 

Milyen gyengeáramú kapcsolatokkal kell számolni? 
Milyen klímatechnológiai feltételeket kell biztosítani? 
Milyen tűzvédelmi feltételeknek kell megfelelni? 
Milyen biztonsági feltételeknek kell megfelelni? 


Végezetül gondoljunk arra, is, hogy mekkora ráhagyással 
dolgozunk a jövőbeli fejlesztésekre! 

Általános tapasztalat, hogy ma körülbelül három évente 
változik a kiszolgálóoldal koncepciója olyan mértékben, 
hogy ez kihat a környezetre is. A nem kellő körültekintéssel 
kialakított infrastruktúra átalakítása, bővítése a későbbiek- 
ben igen költséges lehet, illetve elképzelhetőek olyan ese- 
tek is, ahol nem megvalósítható a változtatás. 


A sivatag 
Nagyon kevés kiszolgálótermet telepítenek a sivatag köze- 
pére, távol minden zavaró szomszédos épülettől, ezért ér- 
demes körülnézni, hogy a leendő szerverterem környeze- 
tében milyen érdekes épületek, objektumok találhatóak. 
Már a helyszín kiválasztásakor fel kell mérni az ebből ere- 
dő kockázati tényezőket. Figyelni kell mind a telephelyen/ 
irodaházban belüli, mind a környező épületekbeli sajátos- 
ságokra. Mind a veszélyességi, mind a biztonsági szem- 
pontokat figyelembe kell venni. 
A teljesség igénye nélkül néhány szempont: 
m Természeti képződmények (vízfolyások, állóvizek) 
m Természeti jelenségek (vihar, hurrikán, monszun stb.) 
m Földrengés, tektonikai tevékenység 
m Veszélyes épületek, létesítmények: 
s üzemanyagtöltő állomás 
s vegyi, könnyűipari, egyéb veszélyes üzem 
2 katonai létesítmények 
s repülőtér 
s pályaudvar 
5 főútvonal 
s szennyvíztisztító 
5 távvezeték, erőmű 
s egyéb nagy forgalmat lebonyolító létesítmény 


Az alapok 

A helyiség kiválasztásakor a fizikai paraméterek azok, 

amelyeken talán a legnehezebb később változtatni. 

Ami mindenkinek eszébe jut, az az alapterület, ezért kell ál- 

talában fizetni. Az alapterület helyes megválasztásához az 

alábbi szempontokat kell figyelembe venni: 

mu Rack: ebből számos méret létezik, más-más mérete- 

ket használnak az egyes gyártók. (Nem árt, ha ezek 
oldalait, ajtaját ki lehet nyitni...) 
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u Ha PC-s eszközöket (is) használunk, akkor nekünk 
kell kitalálni, hogy ezeket milyen polcokon, asztalo- 
kon helyezzük el. 

mu Kábelezés és szerelés. Helyet kell biztosítani az esz- 
közök karbantartására, szerelési munkálatokra és va- 
lahol el kell vezetni a kábeleket is. 

m A rKkkülönféle kábelcsatornák, légcsatornák is eléggé 
sok helyet el tudnak foglalni, ezzel számolni kell. 

m Közlekedés: az eszközökhöz hozzá kell tudni férni. 

m Felkell mérni azt is, hogy üzemszerű működés során, 
illetve krízishelyzetben hány embernek kell ott egy- 
szerre dolgoznia, hozzáférnie az eszközökhöz. 

mum A karbantartáshoz, munkavégzéshez szükséges 
eszközök, szerszámok, kábelek elhelyezésére is 
gondolni kell. 

m Helyet rkell hagyni az esetleges bővítéseknek, fejlesz- 
téseknek. 


Ha túl nagy lett a helyiség, akkor ez az árban jelentkezik. 
Nem csak a kivitelezési, hanem a működtetési /rezsi/ költ- 
ségek is jelentősen függnek a terem méreteitől. 

Ha később túl kicsinek bizonyul a helyiség, a bővítése rop- 
pant körülményes, hiszen nemcsak egyszerűen egy falat 
kell áthelyezni, hanem általában a kapcsolódó gépészeti 
berendezésekhez is hozzá kell nyúlni. Ebben az esetben 
célszerű megfontolni, hogy nem egyszerűbb-e (olcsóbb-e) 
egy másik kiszolgálóhelyiséget kialakítani. 


A dromedárzsiráf, avagy a helyiség 
magassága 

Ez már nem mindenkinek jut eszébe. Fontos tudni, hogy 
egyes elemeknek (elsősorban a rack-eknek) kötöttek a mé- 
retei. Ha túlságosan alacsony a belmagasság, akkor gond- 
ban leszünk ezek beépítésekor. Ügyeljünk az álmennyezet 
és az álpadló méreteire is ! A karbantartási igényeket is ve- 
gyük figyelembe. Ez mind a berendezések, mind a gépé- 
szeti elemek esetén kritikus lehet. (Szomorúan látták a kar- 
bantartók az egyik nagyobb gépteremben, hogy sajnos az 
álmennyezetbe épített berendezésekhez (klímaberende- 
zés, tűzjelző, stb.) egyszerűen nem férnek hozzá a beállí- 
tott rackszekrényektől.) 


A dromedárelefánt, vagyis 

a födémterhelés 

Ez egyike azoknak a paramétereknek, amire általában ke- 
vesen gondolnak. Főleg akkor van jelentősége, ha a kiszol- 
gálótermünket nem a pincében helyeztük el. Nemcsak a 
nagy eszközök súlyosak, ne felejtsük el, hogy sok kicsi 
sokra megy. Nemcsak az egyes berendezések súlyát kell 
figyelembe venni, hanem azt is, hogy ez a súly mekkora te- 
rületen oszlik el. (Lehet, hogy a födém négyzetméterenként 
elbír 1 tonnát, de ha az 1 tonnás UPS-t négy 10 cm-es láb- 
ra állítjuk, akkor az könnyen gondot okozhat.) 

Különösen nehéz berendezések (általában nagyobb teljesít- 
ményű UPS-ek) esetén célszerű statikai vizsgálatokkal meg- 
győződni arról, hogy a célterület kibírja-e egyáltalán a terhe- 
lést. Ilyen eszközök beállításakor célszerű kikérni a gyár- 
tó/szállító véleményét a szerelés, beállítás kérdéskörben. 

A terhelés tervezésekor az álpadló terhelhetőségét is fi- 
gyelembe kell venni. Vagy fordítva, azaz olyan álpadlót kell 
választani, amely elbírja az eszközöket. 


(Például egy rackszekrény (42U) teletömve 1U-s kiszolgá- 
lókkal több mint 800 kg-ot nyom! Ez normál esetben a 
60x60-as, 1000 kg/m? teherbírású álpadlólapokra csak ter- 
heléselosztó alátéttel tehető rá.) 


V mint térfogat 

Most hogy már van alapterületünk, magasságunk, nosza 
szorozzuk össze ezeket. Ekkor egy újabb paramétert, a 
térfogatot kapunk. Ez már átvezet minket a gépészet vilá- 
gába, mégpedig a klimatizálás témakörbe. Itt annyit jegy- 
zek meg, hogy a kiszolgálók illetve a klímaberendezések 
adott idő alatt adott mennyiségű levegőt mozgatnak meg. 
Ennek effektíve el kell férnie a helyiségben. Mindezek mel- 
lett ezt a légmennyiséget mozgatni kell. Ha túl kevés a 
rendelkezésre álló térfogat, akkor a kiszolgálók nem tud- 
nak majd megfelelően hűlni, illetve a klímaberendezés 
nagy szelet kelt a helyiségben, hogy a hőterhelést fel tud- 
ja venni. 


s:Rések a falon, lyukak a plafonon" 
Ez már az East együttesnek is szemet szúrt, akkor nekünk 
is számolni kell vele. Az, hogy hol-mi jön-megy ki-be a 
szerverteremből, szintén befolyásolja, hogy mit és hová 
helyezhetünk el. 
m Milyen ajtók kerülnek beépítésre, hol lesznek, hová, 
merre nyílnak? 
mu Lesz-e a helységben szintkülönbség, rámpa, lépcső, 
stb. 


mu Lesznek-e és ha igen, akkor hol és milyen ablakok? 
Ezek merre fognak nyílni? 

mu Hol lesznek a gyengeáramú ki- és bemeneti helyek? 

mu Hol lesznek az erősáramú beállások? 

m Hol lesz a klíma ki- és beállás? 

mu Lesz-e egyéb gépészeti be/ kiállás? /fűtés, csatorna, 


víz, stb./ 


A különféle nyílászárók kiválasztása során figyelembe kell 
venni az alábbi szempontokat is: 

m méret (beférnek-e rajta a kollégák, akarom mondani 
a tervezett eszközök?) 

m tűzvédelem: milyen tűzvédelmi előírásoknak/követel- 
ményeknek kell megfelelni? 

mu megbízhatóság/használat: a használat jellegére is fi- 
gyelni kell. (Egy forgalmas kiszolgálóterem vagy ope- 
rátor helyiség ajtajának nem célszerű 6-8 perc alatt 
nyitható zsilipkapuk beszerelése, különben a dolgo- 
zók idejük nagy részét ezzel fogják tölteni, esetleg a 
nagy igénybevétel miatt sűrűn kell szervizelni a nyí- 
lászárókat.) 

m zárak és beléptetőrendszerek: ezeknek is illeszked- 
niük kell mind funkcióban, mind használhatóságban 
az elvárásokhoz. 

mM biztonság: milyen igényeknek kell megfelelni? (fizikai 
védelem, elektronikai lehallgatás/sugárzásvédelem, 
stb.) 


Megfontolandó, hogy ablakra egyáltalán szükség van-e 
egy ilyen rendeltetésű helyiségben. A válasz általában az, 
hogy nincs. Igény inkább egy , üvegfalra" szokott lenni, ami 
az operátori/felügyeleti helyiségtől elválasztja a kiszolgáló- 
termet. 


A Fal 

Nem, nem a Pink Floyd művének ismertetése következik, 
hanem vizsgáljuk meg közelebbről a falat, úgyis mindig el- 
megyünk mellette. 

m Jól karbantartható, az igénybevételt jól bíró felületet 
kell kialakítani. Erre a célra általában a különféle 
üvegszálas tapéták felelnek meg. 

mum A tűzvédelemre gondolni kell a tervezésekor. Lehet 
egyszerűbb tűzgátló festéssel is megelégedni, azon- 
ban léteznek ennél jobb védelmet nyújtó komplex 
megoldások is. 

m A Hhelyiség sugárzásvédelmének kialakítása során a 
falakat speciális fóliával/burkolattal láthatják el. 

m Tájékozódjunk arról, hogy az ilyen speciálisan kezelt 
felületekre egyáltalán lehet-e (általában nem!) elhe- 
lyezni valamit, illetve lyukakat fúrni, ragasztani, stb. 


A karavánút - Közlekedési 

és szállítási útvonalak 

Kínos azzal szembesülni, hogy a frissen befejezett helyi- 
ségbe az új eszközt egyszerűen nem lehet odaszállítani. 
(Az egyik neves magyar intézmény géptermébe utólag 
csak két fal kibontásával, daru segítségével lehetett 
beemelni a terjedelmes eszközt.) 

Egy már üzemelő helyiségben eszközöket mozgatni, sze- 
relni, karbantartani jó tervezést, precizitást, figyelmet igé- 
nyel, nehogy a még működő berendezésekben kár essen. 


Az elektromos angolnadromedár, 
vagyis: erősáram 

A delej bevezetése néha nem is olyan egyszerű, mint ami- 
lyennek tűnik. A villanyszerelés és annak célszerű megter- 
vezése rázós feladat. A tervezéskor a felmerült igények 
mellett itt is be kell tartani az elektromos készülékek szere- 
lésére vonatkozó előírásokat. 

Az erősáramú betápokat az alábbiak szerint csoportosít- 
hatjuk: 

m Világítás: a kiszolgálóterem normál megvilágítása. 
Olyan világítótesteket válasszunk, amelyek megfelelő 
megvilágítást biztosítanak berendezett szoba esetén 
is. Általában beépített, az álmennyezetbe illeszkedő 
ipari világítótesteket célszerű választani. A világítás- 
kapcsolónak jól hozzáférhető helyen kell(ene) lennie, 
a bejárat közelében. 

m Vészvilágítás: a kiszolgálóterem pótvilágítása a nor- 
mál hálózat üzemzavara estén. Ennek célszerű auto- 
matikusan bekapcsolni, ha a teremben tartózkodnak 
és a világításban zavar áll be. 

mu Normál hálózat: ez a nem védett erősáramú hálózat. 
Elsősorban munkavégzésre, nem kritikus berendezé- 
sek üzemeltetésére használható. (Egy kiszolgálóte- 
remben nem sok ilyen eszköz van 0) 

m Szünetmentes hálózat: Az eszközeinket ezen a vé- 
dett hálózati szegmensen üzemeltetjük. 

m Egyéb, speciális hálózat (pl.: különféle kisfeszültségű 
beállások 12V. 24V 48v. stb.) Telefonközpontok, spe- 
ciális gépek ellátására lehet rá szükség. 


Meg kell tervezni, hogy a beállásokhoz képest, hol kerül- 
nek elhelyezésre a szükséges elektromos kapcsolószekré- 
nyek, biztosítók, dugaljak, kapcsolók, stb. 
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Kapcsolódik-e, és amennyiben igen, milyen módon 
felügyeleti és/vagy vezérlőrendszerhez? 
Ügyeljünk arra, hogy a terhelést megfelelően osszuk el az 
egyes szegmensek között. (Jó elrettentő példa erre amikor 
az összes eszköz egy láncra felfűzött hosszabbítóban vég- 
ződött ...9) 
A főkapcsolónak könnyen elérhető helyen kell lennie, azon- 
ban nem árt valamilyen védelemmel ellátni a véletlen akti- 
válás elkerülése érdekében. Fontos ismerni a biztosítók el- 
helyezését is, hiszen üzemzavar, illetve karbantartás esetén 
fontos, hogy gyorsan lehessen reagálni. Ezért szükséges a 
megfelelő szakaszolás, a redundancia biztosítása, a külön- 
böző fázisok bekötésének helyes megválasztása, hogy az 
egy fázist, illetve egy szegmenset érintő esetleges üzemza- 
varok hatását mérsékelni lehessen. (Célszerű a redundáns 
tápegységeket külön szegmensekre csatlakoztatni. ) 
A dugaljak elhelyezésére több megoldás létezik, vá- 
lasszunk közülük az igényeknek megfelelően: 

m Álpadló alatt fixen beépítve 
Álpadló alatt mobil dobozban 
Álpadlóba beépített padlódobozban 
Álmennyezetbe épített dobozban 
Álmennyezet alatt futó kábelcsatornában 
Álmennyezet felett futó kábelcsatornában 
Energiaoszlopokon 
A rackekbe beépített energiaelosztó modulokban 


A speciális energiaigényű rendszereknek általában spe- 
ciális kiépítésű csatlakozókra van szükségük, ezzel kap- 
csolatban kérjük ki a gyártó/szállító tanácsát. 


s The show must go on" — 
szünetmentes áramforrás 
A szünetmentes áramellátás tervezése nagy falat, körülte- 
kintést igényel. 
A legfontosabb szempontok: 
mu Mekkora áthidalási időre van szükség? Ennyi ideig 
képes ellátni a külső áramforrás kiesése esetén a 
szünetmentes áramforrás a kiszolgálótermet. 
mu Mekkora időnek kell eltelnie két áthidalási idő között, 
azaz miután visszatért a normál üzembe, mekkora 
idő szükséges a készenléti állapot eléréséhez? 
(Mennyi időre van szükség az akkumulátortelepek 
feltöltésére, stb.) 
mu Milyen rendelkezésre állásalredundanciája legyen a 
szünetmentes áramforrásnak? (Mennyire legyen re- 
dundáns, lehessen-e leállás nélkül karbantartani?) 
mu Milyen védelmet biztosítson a hálózatnak? Pl.: jósági 
tényező javítása, szűrés, túlfeszültségvédelem, stb. 
Ezek alapján lehet akkumulátoros vagy forgógépes ener- 
giatároló rendszert választani. Nálunk az előbbi használa- 
ta terjedt el. 
Ezek után meg kell fontolni, hogy az UPS-hez telepítünk-e 
kisegítő aggregátort. Ennek segítségével, ha rendelkezés- 
re áll megfelelő mennyiségű üzemanyag, akár napokon ke- 
resztül is üzemeltethetjük a kiszolgálótermünket. 
A rendszer méretezése során az összes olyan eszköz fo- 
gyasztását figyelembe kell venni, amelyet rá kívánunk köt- 
ni. A beléptető rendszer, vészvilágítás, illetve hosszabb át- 
hidalási idő esetén a klímaberendezés is szünetmentes 
áramforrást igényel. 


A pókdromedár, azaz a gyengeáram 
A kiszolgálóterem egyik fő feladata a hálózati kiszolgáló-te- 
vékenység. (Ma elsősorban CAT6 UTP kábelezést használ- 
nak.) Célszerű modern csillagpontos kábelezési architek- 
túrát választani. Ne becsüljük alá a végpontszámot! 
Lehetőség szerint a kiszolgálókat és az aktív eszközöket, il- 
letve a kapcsolópaneleket célszerű külön (rackben) elhe- 
lyezni, A kapcsolópanel, illetve az aktív eszköz elhelyezé- 
sekor ügyelni kell az átkötő kábelek elhelyezésére, elveze- 
tésére, különben hamar kialakulhat a teljesen kaotikus 
kábeldzsumbuj, ami idővel mindent elnyel... 9 

A dugaljak elhelyezése az előző bekezdésben leírtak sze- 
rint az erősáramú dugaljakéhoz hasonlóan történhet. 


Az esetlegesen beépítésre kerülő egyéb gyengeáramú 
végpontok esetében hasonlóan járjunk el az UTP végpon- 
tokénál leírtakhoz, figyelembe véve az eltérő technikai kivi- 
telezésből adódó különbségeket. 


Fény az alagút végén - optika 

Egyre elterjedtebbek az optikai hálózatok. Ezeket a nagy 
sebességű összeköttetéseket leggyakrabban távoli telep- 
helyek összeköttetésére, központi háttértárak, szalagos tá- 
rak elérésére használják. Ezek az eszközök érzékenyek, 
oda kell figyelni a mechanikai hatásokra. (Könnyen törhet- 
nek, sérülhetnek a megfeszülő csatlakozók, kábelek.) Be 
kell tartani a csatlakozók, lengőkábelek kezelésére, tárolá- 
sára vonatkozó szabályokat. Mind a csatlakozók, mind a 
vezetékek szereléséhez, bekötéséhez speciális szerszá- 
mokra, szakemberre van szükség. 


A dromedár pálmalevele - klíma- 
technika 

A kiszolgálóterem temperált helyiség, azaz az eszközök 
szeretik, ha viszonylag állandó klimatikus viszonyok ural- 
kodnak benne télen-nyáron. Az általános ajánlás a 22 "C, 
50 százalékos relatív páratartalom, de az egyes berende- 
zéseken általában fel van tüntetve, hogy milyen klimatikus 
viszonyok között érzik jól magukat. Külön fűtésre általában 
nincs szükség, az eszközök meglehetősen sok hulladék- 
hőt termelnek, ami felmelegíti a termet. 

A mai eszközök nagy többsége léghűtéssel üzemel, azaz 
levegőt szív be, fúj ki. A hatékony hűtéshez az eszközök 
szellőzőnyílásait szabadon kell hagyni, az eszköz leírása 
szerint. Figyelni kell arra, nehogy az egyik eszköz gátolja 
a mellé beszerelt másik eszköz hűtését. Általában a leve- 
gőt a padlószinten, vagy az álpadló alatt juttatják a helyi- 
ségbe, és az álmennyezetbe épített elszívókon keresztül 
juttatják ki. Így a keletkező, felszálló hő elvonása hatéko- 
nyan megtörténhet. Célszerű úgy megválasztani a ki- és 
bemeneti csatornákat, hogy ne alakuljon ki szélhatás, illet- 
ve a befújt levegő ne tudjon közvetlenül az elszívón ke- 
resztül távozni. 


A klímaberendezés tervezését, kivitelezését a felhasználó 
igényei szerint klímatechnikai szakértő bevonásával kell 
végezni. A kiszolgálóhelyiségekbe alapvetően háromféle 
klímaberendezés telepítése megfontolandó. Az úgyneve- 
zett szekrényklímák teljes egészében a kiszolgálóterem- 
ben kerülnek elhelyezésre. Előnyük: a megbízhatóság, 
azaz önálló egységet képeznek, függetlenül üzemelnek re- 


Ó 
o 


B a 0 1 


dundanciájuk több darab beállításával biztosítható. (Pl.: az 
épületben máshol történt tűzeset, katasztrófa, üzemzavar 
esetén is működnek.) Hátrányuk: zajosak, a nevükhöz 
hűen sok helyet foglalnak el, a kondenzvíz a helyiségben 
keletkezik, azt innen kell elvinni, karbantartani is értelem- 
szerűen itt kell. 

A másik szóba jöhető típus a légcsatornás klímaberende- 
zés. Előnye, hogy a helyiségben nem foglal sok helyet, itt 
csak a levegő ki- és bevezetőnyílások vannak, no meg az 
érzékelők. A gépek egy külön helyiségben kapnak helyet, 
vagy egyszerűen a tetőre vannak telepítve. Ezek jóval 
csendesebb üzeműek (a kiszolgálóteremben), és a kon- 
denzvíz (legnagyobb része) is a helyiségen kívül marad. 
Általában ezt a klímaberendezést több más helyiség 
klímatizálására is fel lehet használni. Hátrányuk, hogy na- 
gyon összetett, bonyolult rendszerek, bármelyik részegy- 
ség meghibásodásakor általában a teljes rendszer leáll. 
Karbantartásuk is komoly szakértelmet igényel. A hosszú 
légszállítási útvonalak is kockázati tényezőt jelentenek. 
Kisebb termek költséghatékony klimatizálására használa- 
tosak még a hagyományos split, illetve parapet rendszerű 
berendezések is. Ezek teljesítménye, rendelkezésre állása, 
megbízhatósága általában elmarad a nagyobb rendszere- 
kétől. Többnyire a páratartalmat sem tudják kellőképpen 
szabályozni. 


A sivatag pora 

Tulajdonképpen a klímaberendezés része a szűrőberende- 
zés. A kiszolgálók egy idő után nem jól tűrik a por, lég- 
szennyezés jelenlétét. A nagymennyiségő levegő átszívá- 
sa eredményeképpen a kritikus helyeken felgyűlhet a por. 
Ez elsősorban a mozgó alkatrészekkel rendelkező eszkö- 
zök meghibásodásának kockázatát növeli. Ilyen érzékeny 
eszközök elsősorban a háttértárolók, szalagos tárolók. Az 
adatok nagy része pedig éppen itt található! 

A jól megtervezett, jól beállított berendezés is csak akkor 
fog hatékonyan működni, ha a karbantartásokat rendszere- 
sen elvégzik, a helyiség használati szabályait betartják. 
(pl.: szűrőcsere, a berendezéstől függően akár hetente is! 
Az ajtókat nem hagyják nyitva, stb.). 


Egyéb gépészeti berendezések 

Ha lehet, akkor olyan gépészeti berendezést, amire nincs 
szükség a gépteremben, ne is vezessünk át rajta. (pl. víz, 
fűtés, szennyvíz) mert ezeknek a meghibásodása is ko- 
moly károkat okozhat. 


A tábortűz melege - tűzvédelmi 
berendezések 
Sokféle megoldás között lehet válogatni pénztárcánk és 
igényeink függvényében: 
mum ANlegegyszerűbbek a helyi érzékelők. Ezek hang és/ 
vagy fényjelzésre képesek. 


mu Összetett érzékelőrendszerek. Többféle, akár külön- 
böző elven működő érzékelő adatai alapján már intel- 
ligensebben észlelhetik korai stádiumban a tüzeket. 
Kiviteltől függően más rendszerekhez (felügyeleti, 
biztonsági, stb.) is kapcsolódhatnak. 

mu Automatikus oltásvezérlő, illetve oltórendszerek. 
Ezek a komplex rendszerek nem csak észlelni képe- 
sek a tüzeket, hanem képesek beavatkozni is, így ké- 
pesek megelőzni a nagyobb kárt. 


A dromedár póráza - Biztonság 
Célszerű a biztonsági kérdéseket külön kezelni, ha lehet, 
független szakértő segítségével feltérképezni, megtervez- 
ni a terem biztonsági berendezéseit. Ez önmagában akko- 
ra szelet, hogy külön tárgyaljuk. Itt vázlatosan néhány gon- 
dolatot ismertetek: 
m Passzív védelem: ajtók, rácsok, egyéb fizikai akadályok. 
m ArHhelyiség leárnyékolása. 
m Zárak: a nyílászárók nyitását gátló berendezések. 
5 mechanikus (hagyományos zárak) 
. logikai (valamilyen kulcsnélküli kombinációs 
megoldás: pl.: széfzárak) 
s elektromos/elektronikus (kártyák, számkódok, 
stb.) 
" biometrikus kiegészítések: általában az elektro- 
nikus zárak kiegészítői. 
mu Behatolás észlelő berendezések (riasztóberendezés) 
Figyelembe kell venni, hogy egyes szenzorok nem 
működnek megfelelően egy zsúfolt, üzemelő gépte- 
remben. 
mu Megfigyelőrendszerek: általában képrögzítő beren- 
dezések. 
mu Beléptető rendszerek: a személyforgalom automati- 
kus lebonyolítását és naplózását végzik. 
m Élőerő alkalmazása. 
mu Teherforgalom monitorozása. 
mum Személyforgalom monitorozása. 


Záró gondolatok 

A leggondosabb tervezés után is állhatnak elő problémák 
a gépterem használatbavétele után. A felhasználói igények 
is változnak, ahogyan az üzletmenet változik. A technoló- 
giai lehetőségek is változnak idővel. Mindezekből az követ- 
kezik, hogy egy működő kiszolgálóterem folyamatosan vál- 
tozik. Ezek a változások néha szembeötlőek, máskor egé- 
szen jelentéktelenek. A tervezés előnyeit (sajnos a hibáit is) 
hosszú időn át élvezhetjük, a mindennapi üzemeltetés so- 
rán is. 


MEGYESI BARNABÁS 
megyesi.barnabasameb.bu 
üzemeltetésvezető 

MCSE, , dromedárszakértő" 
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vVVindows 


szolgáltatások 


ALAPOK ÉS KEZELÉS 


A szolgáltatások kritikusan fontos szerepet töltenek 


be a VVindows kiszolgáló és munkaállomás 


operációs rendszerek, sőt, az ezeken futó alkalmazások 


tekintetében is. Nem árt tehát tisztában lenni szerepük- 


kel, működésükkel, feladataikkal és lehetőségeikkel. 


Csak szép sorban 

A legtöbb alkalmazás interaktív. Igény szerint kattintunk, in- 
dul, fut, kattintunk, leáll. Ez így egyszerű világ, de persze 
nem elég ennyi funkcionalitás. Szükség van más típusú 
megoldásokra is, amelyek nem az interaktív alkalmazáso- 
kat kontrolláló felhasználókhoz kötődnek (de gyakorlatilag 
minden felhasználót kiszolgálnak, még akkor is, ha nincs 
bejelentkezve egy sem), amelyekkel lehetséges az erőfor- 
rások folyamatos kezelése az operációs rendszer indításá- 
tól annak leállításáig. Ezért egy ilyen szolgáltatás általában 
egy csendesen a háttérben futó alkalmazást, folyamatot 
vagy esetleg ez utóbbiak gyűjteményét jelenti. Röviden 
szerviznek is szoktuk emlegetni, vagy éppen szervíznek 
(az hogy rövid vagy hosszú i-vel írjuk a nyilvánvaló helyes- 
írási szabály ellenére számomra sem teljesen világos, így 
is, úgy is láttam már leírva elvileg komoly dokumentumok- 
ban, weboldalakon is). Többnyire a szervizek egy adott 
funkciót teljesítenek pl. más programok támogatását és ezt 
alacsony (de általában nem hardverközeli, mint a device 
driverek) szinten teszik. Olyan alapfeladatokat látnak el az 
operációs rendszer részeként, mint a webszolgáltatások, a 
naplózás, az állomány és nyomtató szolgáltatások, a repli- 
kációs szolgáltatás vagy éppen a távoli eléréssel kapcso- 
latos szolgáltatások. Közös tulajdonságuk még az is, hogy 
általában nincs külön kivezetett felhasználói felületük, 
nincs is szükségük erre a korrekt a működéshez, sőt ez sú- 
lyos biztonsági problémákhoz is vezethetne. A szervizek 
további jellemzője, hogy gyakran implementálják a szer- 
veroldalt a szerver/kliens kapcsolatokat megvalósító alkal- 
mazásokban, például az operációs rendszer alatt futó 
webszerverek esetén. 


Természetesen az operációs rendszer beépített, a telepí- 
tés után rendelkezésre álló rendszer szolgáltatásain kívül a 
külső komplex kiszolgáló- vagy egyszerűbb alkalmazások 
(levelezés, adatbázis, tűzfal, proxy, vírusírtó, távmenedzs- 
ment szoftverek, stb.) saját szolgáltatásai is bekerülhetnek 
az alkalmazás telepítésekor a szolgáltatások közé, és rezi- 
densen elérhetővé válhatnak az anyaalkalmazásaik szá- 


mára. De arra is van mód, hogy tetszőleges futtatható állo- 
mányból mi gyártsunk szervizeket manuálisan. 


Tetszetős rövidítések jönnek 

Egy Win32 szerviznek mindig szüksége van három kompo- 
nensre: a szerviz alkalmazásra (Service Application), a ve- 
zérlő programra (Service Control Program - SCP), és a 
szervizkezelőre (Service Control Manager — SCM). A szer- 
viz alkalmazás jelentheti pl. a már említett webszerver 
holdudvarába tartozó végrehajtható állományt 
(Inetinfo.exe), amely aztán a webszerver telepítésekor 
szervizként futtathatóvá válik. Egy SCP segítségével ezt 
aztán el is indíthatjuk, ideiglenesen megszakíthatjuk, majd 
folytathatjuk, vagy akár végleg le is állíthatjuk. Windows 
környezetben, grafikus felületen ez lehet pl. az MMC, a vi- 
deomagnóknál megszokott 80 egyezményes jelű gombok- 
kal, de természetesen az egyedi alkalmazásoknak lehet 
saját, beépített vezérlője is (pl. SOL Server Notification ve- 
zérlő ikon a Tálcán). Parancssorból pedig a ,net start/ 
pause/stop" parancsok állnak rendelkezésre erre a célra, 
vagy pl. a Resource Kit tartalmazza az Sc.exe-t [1], amely 
borzasztóan széleskörű lehetőségekhez ad hozzáférést, a 
parancssort kedvelők számára. A harmadik komponens, 
az SCM kommunikál a szervizekkel, utasításokat ad és 
visszajelzéseket kap pl. az állapotukról. A Service Control 
Manager a 97oSystemRootyASystem3AServices.exe állo- 
mányban található (amely tartalmaz jónéhány beépített 
szervizt is), és fontos szerepe van a rendszerindításkor (is). 
Miután a Winlogon processz a bootolás korai szakaszában 
elindítja az SCM-et, az ebben lévő indító rész 
(SveCtrIMain) elkezdi az automatikus indulásra beállított 
szervizeket betölteni a regisztrációs adatbázis 


HKLMVSYSTEMCurrentControlSetControlNV 
t  ServiceGroupOrder 


kulcsában lévő sorrend alapján. A betöltés több fázisban 
valósul meg, egy fázis egy csoportnak felel meg. Ez a fo- 
lyamat körülbelül a növekvő kék csíkos képernyő és a 
GINA (Graphical Identification and Authentication) beje- 
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lentkező képernyőjének (ez a jólismert Logon Window) be- 
töltése között történik meg. 


Services MMC 

Amikor egy olyan programot telepítünk, amely tartalmaz a 
program működéséhez szükséges szervizt, akkor a telepí- 
tő programnak gondoskodnia kell ezen szerviz regisztrálá- 
sáról az operációs rendszer számára. Ezért ekkor a re- 
gisztrációs adatbázisban létrejön egy egyedi kulcs a kö- 
vetkező szakaszban: 


HKLMYSYSTEMNCurrentControlSettServices 


Az adott kulcs, a benne lévő számos paraméterrel mara- 
dandóan jellemző az adott szervizre, ergo tekinthetjük ezt 
a szakaszt az SCM adatbázisának (persze ebben benne 
vannak a device driverek is, merthogy azokat is az SCM 
kezeli). Ennek a felhasználó számára is kényelmesen ke- 
zelhető leképezése egy közismert SCP, a Services MMC. 


Ebben az MMC-ben (elérhető az Administrative Tools prog- 
ramcsoportból, vagy a My Computer helyi menüjében a 
Manage pont alól a Management MMC-ben, vagy akár egy 
mme.exe indítása után is hozzá lehet adni mint bővítményt) 
összesen 5 oszlopot lehetséges elővarázsolni, ezek a szer- 
vizek nevét (Name), a leírásukat (Description), az aktuális 
állapotukat (Status), az indítás típusát (Startup Type) vala- 
mint a szervizt futtató felhasználó nevét (Log On As) tartal- 
mazzák. Ebből ránézésre az utolsó két oszlop az igazán 
érdekes (talán még az állapot is, főleg ha baj van 0). Az 
alapfeladatokat (indítás, leállítás, stb.) ebben a keretben el 
is láthatjuk, de egy-egy szerviz tulajdonságlapján ezek 
mellett további konfigurálási és információs lehetőségeink 
vannak. 


A szervizek tulajdonságlapjai 


A General (Általános beállítások) panel 

A General fülön felül a rövid név, a normál név és a leírás 
mezők közül egyik sem túl izgalmas, bár a rövid név isme- 
rete azért jól jöhet a parancssorban, hiszen pl. a szervizt 
leállító ,net stop" parancs után ezt a formulát kell beírnunk, 
hacsak nem akarjuk idézőjelek közé a hosszú nevet bevés- 
ni. A rövid név nem mindig logikus, erre jó példaként fel 
tudnám hozni az Indexing Service-t (cisvc), vagy a Win- 
dows Time szolgáltatást (w32time), viszont az 


sc getkeyname 


paranccsal bármelyik szerviz rövid nevét megkapjuk pa- 
rancssorból is, 

Ezek alatt viszont máris láthatunk egy lényegesen érdeke- 
sebb dolgot a , Path to executable" sort megvizsgálva, el- 
sőként mondjuk az Alerter szolgáltatásnál. A várt 
Alerter.exe állomány helyett (mint pl. a File Replication 
Service-nél az Ntfrs.exe) egy teljesen más állomány szere- 
pel, konkrétan ez: 


C:WWINNTYVSsystem32iSvchost.exe -k LocalService 


Sőt, pontosan ugyanezt az útvonalat látjuk pl. a Web Client 
szolgáltatásnál is, meg még 1-2 másik szerviznél is. Ez 
azért van, mert nem minden szerviz külön állomány, hanem 


léteznek olyan DLL-ekbe helyezett processzek is, amelyek 
azért ettől még szervizként operálnak. Ezek viszont csak 
az Svchost.exe égisze alatt tudnak futni. Feltűnő módon, 
több példányban is láthatjuk ezt az állományt pl. a Task 
Manager taszklistájában, amelynek a magyarázata az, 
hogy az Svchost.exe az operációs rendszer induláskor ki- 
sebb-nagyobb csoportokba gyűjti az ilyen processzeket 
és csoportonként egy-egy Svchost.exe példány futtatja a 
csoportba tartozó elemeket. Ezeket a csoportokat megte- 
kinthetjük a regisztrációs adatbázisban a következő kulcs 
alatt: 


HKLMYSoftwareWMicrosoftWindowsNTXCurrentVersiont 
$ Svchost 


Az Alerter szerviz esetén tehát a ,Local Service" jelenti a 
csoport nevét és a Registry alapján ide tartoznak (egy fris- 
sen telepített Windows Server 2003 alatt) még a követke- 
zők is: 

m Alerter 

m WebClient 

mum LmHosts 

m WinHttpAutoProxySvc 


Ha ki szeretnénk nyomozni, hogy a taszklistában szereplő 
Svchost.exe-k közöl melyikhez tartozik a mi Alerter szervi- 
zünk, akkor ezt a csoport PID-je (Process IDentifier) alap- 
ján tehetjük meg. Indítsuk el a Task Managert és a 
Processes fül alatt láthatjuk is a többpéldányos 
Svechost.exe-t. Alapértelmezés szerint a PID nem látszik, 
de a View/Select Colums menüpont alatt kiválasztható. 
EEKZZZTEK ZET KET SNEK neme zola 
Ele Options Yiew Help 
Applications . Processes ] performance ] Networking [ users ] 


1732 Administrator 
400 SYSTEM 
276 SYSTEM 
1236 SYSTEM 
1640 SYSTEM 


11916K 
480K 
4724K 
3732K 


628 SYSTEM 
880 NETWORK SERVICE 
896 LOCAL SERVICE 
924 SYSTEM 
1436 SYSTEM 
1608 LOCAL SERVICE 
1944 SYSTEM 
4 SYSTEM 
0 SYSTEM 
784  Administrator 
1788 SYSTEM 
1696 SYSTEM 
3020  Administrator 


3920K 
4120K 
2172K 
16 200K 
1724K 
1320K 
S5S508K 

216K 

16K 
1192K 
8620K 
1548K 
2164K 


System Idle Process 
taskmgr.exe 
tcpsvcs.exe 
VMwareservice.exe 
VMwarelser.exe 


8888888888888H88888 








A processzek listája a PID-ekkel 
kiegészítve 


Az előző képen látható negyedik, a 896-os PID-et birtokló 
Svchost.exe a LocalService csoport példánya (ne té- 
vesszen meg bennünket ugyanez a név a User Name osz- 
lopban, az mást takar), konkrétan e mögé bújva működik 
az Alerter szolgáltatás. Hogy ez honnan derült ki?? A 
megoldáshoz futtassuk parancssorból a 


tasklist /svc 
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parancsot (a Windows 2000-nél és az NT4-nél még 
Tlist.exe-nek hívták), és ekkor olyan összerendelést látha- 
tunk, amelyben az Svchost.exe példányok és a csoport 
PID-ek mellett a különböző csoportok tagjai is ki vannak lis- 
tázva (de csak az aktuálisan működők). 

Ha továbbmegyünk a General panelen, akkor a szervizek 
indításával kapcsolatos opciókat láthatjuk. Három lehető- 
ségünk van: Automatic, Manual, Disable. Szabadon válto- 
gathatunk a szervizek ezen állapotai között, de csak óva- 
tosan, mert egyrészt megbéníthatjuk vele az alkalmazá- 
sainkat, másrészt felesleges biztonsági rizikót generálha- 
tunk viszonylag könnyedén. Egyébként, ha már a bizton- 
ság szóba jött, megfigyelhető pl. az a változás, hogy a Mic- 
rosoft egyre kevesebb szervizt indít el gyárilag automatiku- 
san az operációs rendszerek vagy a kiszolgáló alkalmazá- 
sok tekintetében, és egyre többet tilt le. Végiggondolva ezt 
a törekvést, ez így helyesnek is tűnik, hiszen ez egy újabb 
pozitív dolog a ,minimális szükségesség" elv mentén. 
Azonban megfelelő információ híján érdekes élményben O 
lehet részünk pl. az Exchange 2003 Server új telepítése 
után (frissítésnél nem), mert alapból már a POP3 vagy 
IMAP szervizek is le vannak tiltva [2]. De a Windows XP 
SP2 után is lesz ilyen élménye a kevéssé tájékozott üze- 
meltetőnek, hiszen a jelenlegi állás [3] szerint a szervizcso- 
mag pl. az Alerter vagy a Messenger szervizt szintén letilt- 
ja. Jöjjön viszont egy ömlesztett felsorolás azokról a szer- 
vizekről, amelyek Windows 2000-ben vagy az XP-ben au- 
tomatikusan indulnak vagy manuálisan indíthatók voltak, 
ellenben a Windows Server 2003-ban le vannak tiltva (vagy 
egyszerűen csak nincsenek telepítve): Alerter, ClipBook, 
Distributed Link Tracking Server, IMAPI CD-Burning COM 
Service, Internet Connection Firewall and Sharing, 
Messenger, NetMeeting Remote Desktop Sharing, Network 
DDE DSDM, Network DDE, Remote Registry, Telnet, 
Terminal Services Session Directory, Themes, Web Client, 
Windows Audio, Windows Image Acauisition, IIS Admin, 
Simple Mail Transfer Protocol, World Wide Web Publishing. 
Szép kis lista! 

Természetesen ahhoz, hogy egy letiltott szolgáltatást elin- 
díthassunk, először automatikus vagy manuális állapotúvá 
kell tennünk, és csak ezután lehet a Start gombra bökni. 
Vannak olyan szervizek is (pl. az IISAdmin), amelyek vi- 
szont ideiglenesen megállíthatók a Pause funkcióval, ha vi- 
szont az ideiglenes megállítás oka megszűnik, akkor akár 
újraindíthatjuk vagy akár rávehetjük folytatásra is a 
Resume gombbal. A General panel alján egyébként arra is 
lehetőségünk van, hogy az adott szervizt paraméterezve 
indítsuk el. 


A Log On (Bejelentkezés) panel 

A Log On panel a szervizekkel kapcsolatos biztonsági en- 
gedélyek egy részébe enged betekintést: itt tudjuk a szer- 
vizhez rendelt felhasználói fiókokat megtekinteni és 
amennyiben szükséges megváltoztatni. Ez az ún. szolgál- 
tatásfiók engedély (Service Account Permission). Egy fris- 
sen telepített Windows XP/Windows Server 2003 operációs 
rendszer esetén háromféle jogosultsága lehet alapesetben 
egy szerviznek: Local System, Local Service és Network 
Service. Az esetek túlnyomó részében a Local System (He- 
lyi rendszerfiók) jogosultságot használja a rendszer. Ez egy 
speciális és egyedi fiók, amelyet csak helyben használha- 
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tunk és nem jó sem az interaktív belépésre, sem hálózati 
erőforrások elérésére. Talán legjobban az Administrator 
fiókra hasonlít, mert a deklarált maximális jogosultsággal 
teljesen elérhet mindent (a tartományvezérlőn pl. a teljes 
címtárat), de a hasonlóságnak itt vége is van, hiszen nem 
tartozik bele az operációs rendszer jogosultsági rendsze- 
rébe, inkább az , alatt" vagy ,mellett", mindenesetre ennek 
hatókörén kívül operál (a Trusted Computer Base része). 


DHCP Client Properties (Local Computer) MEeLzí2d 
General Log On I Recovery] Dependencies ] 
Log on as: 


€C Local System account 
TT állogi service to interact with desktop 


Ge Nr AUTHORITYNNetworkS erv Browse... I 
Password: 
Confirm password: [essssssssssssse 





You can enable or disable this service for the hardware profiles listed below: 
Service 
Enabled 









Original Configuration 





Enable I Disable I 





Cancel ] Apply I 





A DHCP kliensnek elég a Network 
Service fiók 


A további két fiók már gyengített jogkörű az új biztonsági 
elveknek megfelelően. Nyilván ennek értelmét az adja, 
hogy amennyiben ezek a szervizek vagy az alkalmazásaik 
támadás áldozatává válnak, akkor a behatoló ne kapjon 
korlátlan jogosultságot, sem helyi, sem hálózati viszonylat- 
ban. A Local Service fiók (Helyi szolgáltatásfiók) szintén 
speciális, az autentikált felhasználói fiókokhoz hasonló 
fióktípus. Az erőforrásokhoz és az objektumokhoz ugyan- 
azt a hozzáférési szintet biztosítja, mint ami a Users cso- 
port bármely tagja számára rendelkezésre áll, és szintén 
csak kizárólag a helyi gépen használható. A Network 
Service (Hálózatszolgáltatás) fiók pedig nevéből adódóan 
a hálózati szolgáltatásokhoz van rendelve, a Local Service 
fiókkal megegyező, szintén erősen csökkentett jogkörrel 
rendelkezik és a számítógépfiók hitelesítő adatait használ- 
ja a hálózati erőforrásokhoz való kapcsolódáskor szüksé- 
ges autentikáció során. 


Persze ha szükséges, bármely a rendszerben meglévő fel- 
használói fiókot is hozzárendelhetünk egy szervizhez, de 
ezt azért lehetőleg nagy körültekintéssel kövessük el. 
Miért? Néhány ellenérv, ami a három alapértelmezett fiók 
és a közönséges fiókok különbségeire is rávilágít: 


1. A közönséges fiókok jelszava egy optimális rendszerben 
x időközönként lejár. Amikor még Exchange 5.5-öt hasz- 
náltunk (ahol muszáj volt egy külön fiókot beállítani az 
Exchange szervizeknek), rendszeresen belefutottam en- 


nek az amúgy korrekt dolognak a hátulütőjébe: mindig 
akkor járt le a jelszó, amikor épp három vagy több napig 
távol voltam O. Persze megtehetjük azt is, hogy nem ál- 
lítunk be lejárati időt, de ez már kompromisszum. 


2. Másik probléma, hogy a féltve óvott és (szerintünk) opti- 
mális rendszerünkben a fiókzárolás házirend engedé- 
lyezve van. Ha kiderül a fióknév és valaki sportból pró- 
bálkozik, a fiók kizáródik, ezért a nevében futó szolgál- 
tatás megint csak nem fog működni rendeltetésszerűen 
egészen a feloldásig. A fiókzárolás tartományi szintű há- 
Zirend opció, akkor ezért az egy dologért ne használjuk 
az adott tartományban? 


3. További probléma lehet az, hogy ha olyan fiókot válasz- 
tunk, amelynek nincs engedélye a szolgáltatásként törté- 
nő bejelentkezésre. Ekkor az operációs rendszer ugyan 
automatikusan megadja számára azokat a felhasználói 
jogokat, amelyekre ehhez szükségesek, de ez még min- 
dig nem teljesen garantálja, hogy el is indul a szolgálta- 
tás. Ezért ilyenkor vagy kinyomozzuk és leteszteljük pont- 
ról pontra, hogy milyen jogok kellenek az adott fióknak és 
reménykedünk, hogy ez így jó lesz, vagy a könnyebb utat 
választjuk, és lazán beemeljük az adott fiókot, mondjuk a 
Domain Admins csoportba (a biztonság kedvéért, mert 
,Ha lúd, legyen kövér" 80). Hmmm. 


Szóval csak óvatosan, inkább bízzunk meg az operációs 
rendszer sugallta megoldásban. De ha már a szervizekkel 
kapcsolatos biztonsági feltételekre koncentrálunk, szót kell 
ejtenünk a fiókjogosultságok melletti másik engedélytípus- 
ról, mégpedig az előbb már említett szolgáltatási engedé- 
lyekről. Az összes szolgáltatás rendelkezik a felhasználó(k) 
vagy csoport(ok) számára megengedő vagy megtagadó 
engedélyekkel. A Windows 2003 Serverben az egyes szol- 
gáltatások engedélyeit a Csoportházirendben (lásd ké- 
sőbb) vagy a szintén már említett Sc.exe segítségével mó- 
dosíthatjuk. Összesen 14 féle jogosultságról van szó, ame- 
lyek között szerepel természetesen pl. az indítás vagy a 
leállítás, de olyan extrák is, mint az Enumerate depen- 
dents, amellyel meghatározhatjuk a megadott szolgáltatás- 
tól függő egyéb szolgáltatásokat. 

A Log On panelen kapott helyet a hardverprofilonként le- 
hetséges szerviz engedélyezészítiltás szelekció lehetősége 
is. Természetesen csak akkor (ezt eddig nem említettem, 
de értelemszerű) ha az Administrators vagy tartomány ese- 
tén a Domain Admins csoport tagjai vagyunk, vagy dele- 
gálással megkaptuk az engedélyt. 


A Recovery (Helyreállítás) panel 
Az itt található lehetőségek a Windows 2000-rel érkeztek, 
és jelentősen kiszélesítik eszközeinket abban az esetben, 
ha valami negatív változás áll be a szervizek állapotában. 
Három állapotváltozáshoz (First Failure, Second Failure és 
Subseguent Failure, azaz Első, Második és További hibák) 
rendelhetünk különböző műveleteket a legördülő menük 
segítségével, azaz: 

m Take no action - azaz , Semmi ne történjen" 

mu Runa program - egy program futtatása 

mu Restart the Service - a szerviz újraindítása 

mu Restart the Computer - a gép újraindítása 


DHEP Client Properties (Local Computer) 
General] LogOn Recovery I Dependencies ] 
Select the computers response íf this service fails. 





First failure: [RunaProgam 7] 
Second failure: [RestantheService 5] 
Subseguent falures: f[Restanthe Computer 5] 
Reset fail count aíter MO das 
Rtestart service alter: B 0 minutes 

Run program 

Program 


[e Neventsend. exe Browse... ] 
Command line parameters: [ 


TT áppend fail count to end of command line [/fail:2z122) 


Bestart Computer Options... I 











bo 1] cme [/ ar ] 








Ez a szerviz alaposan fel van készítve 
a hibákra 


Abban az esetben, ha a tetszőleges program futtatását vá- 
lasztjuk (pl. egy üzenetküldő programot, amely egy e-mailt 
fog küldeni nekünk), akkor a panel alján meg kell adnunk a 
program elérési útját (UNC név nem lehet), esetleges para- 
métereit, valamint az , Append fail count to end of command 
line" négyzet kipipálásával megadhatjuk, hogy a hibaszám- 
láló legyen az utolsó paraméter. A 99199 mezőt a hibaszám- 
láló minden alkalommal felülírja, így az alkalmazás vagy pa- 
rancsfájl ennek az értéknek a függvényében különböző mű- 
veletet hajthat végre. Néhány szerviz esetén alapértelme- 
zés szerint be van állítva egy-egy program futtatása, pl. ha 
megnézzük az IISAdmin szervizt, akkor a nevében a funk- 
cióját hordozó lisreset.exe-t láthatjuk viszont, amely képes 
korrekt módon kezelni az IIS környezetét hiba esetén. 

A Restart Computer Options gomb alatt pedig lehetősé- 
günk van az újraindítás kiváltását tetszőleges percre elha- 
lasztani, valamint az automatikus üzenetküldésre (a net 
send-del, pl. a bejelentkezett felhasználóknak) nyílik mód 
még az újraindítás előtt. 


A Dependencies (Függőségek) panel 

Ezen a panelen csak információkat találunk, ám adott eset- 
ben ezek kulcsfontosságúak lehetnek. A lap felső részén 
(,This service depends of the following system compo- 
nents") azokat a szervizeket látjuk, amelyek korrekt műkö- 
dése hiányában az aktuális szervizünk nem fog elindulni. A 
lap alján (The following system components depend on 
this service") pedig azokat, amelyek az aktuális szerviz ál- 
lapotától függnek. A rendszerben mindkét függőségi fajtá- 
nak léteznek tipikus képviselői, pl. az RPC (Remote 
Procedure Call - Távoli eljáráshívás) szerviztől több mint 40 
egyéb szerviz függ (míg ő egytől sem), de a Workstation, 
Server vagy a COM-- Event System szolgáltatás működésé- 
nek hiánya is riadalmat kelthet. Vannak persze olyan szervi- 
zek is, amelyek viszont alaposan ki vannak szolgáltatva 
más szervizeknek, mint pl. a Distribution File Service (ami 
ráadásul pár szerviz mellett még device driverektől is függ). 








IIS Admin Service Properties (Local Computer) 
General] Log On ] Recovery Dependencies ] 


Some services depend on other services, system drivers or load order 
groups. If a system component is stopped, or is not running properly, 









tt services can be affected. 


1IS Admin Service 
"UDS SEN OS ESPSOS SOS LÉKBOG estem gONpOtetAk 









GY Bé Té] 
a 8 Szolg A Gvgée Manager 
E égy Remote Procedure Call (RPC) 


The following system components depend on this service: 

HTTPSSL 
gy World wide Web Publishing Service 

gy Microsoft POP3 Service 

fa. Simple Mail Transfer Protocol (SMTP) 

€fy World wide web Publishing Service 










Cance 7 áony 





Az HSAdmin szerviz függ és sakkban tart 


A Csoportházirend hatásai 

a szervizekre 

Szó volt már a szolgáltatási engedélyekről, amelyeket a 
Csoportházirendben (és csak abban, a Helyi házirendek- 
ben nincs ilyen lehetőség) szerkeszthetünk. Emellett hasz- 
nálhatjuk még a Csoportházirendet más célokra is, pl. köz- 
pontilag néhány kattintással kötelezően elindíthatunk szer- 
vizeket egy adott csoportba tartozó kliens gépeken. Gyárt- 
hatunk ehhez egy külön GPO-t, vagy beilleszthetjük egy 
meglévőbe is, mindenesetre mindenképpen ide navigál- 
junk: Computer Configuration 2 Windows Settings 2 
Security Settings 2 System Services. Itt megtaláljuk az alap 
szervizeket, amelyek közül bármelyikre kettőt kattintva a kö- 
vetkező képen látható panelt vehetjük szemügyre. Itt éppen 
az Automatic Updates szerviz kötelezővé tétele látszik, ami 


Automatic Updates Properties dd P.4 


Security Policy S etting ] 
LEV 
[7 Defnethis poligy setting 


Select service startup mode: 
(7 Autornatic 

E Manual 

C Disabled 


Edit Security... I 


Automatic Updates 





box ] ceea [/ 6rww ] 





Pofonegyszerű minden gépre kötelezően en- 
gedélyezni vagy tiltani egy szervizt 


e 


konkrétan is előfordulhat pl. abban az esetben, ha éppen 
bevezetjük a SUS-t, és biztosak akarunk lenni abban, hogy 
minden kliens (csak a Windows 2000 SP4, az XP SPI és a 
Windows Server 2003 tartalmazza ezt a szervizt) futtatja 
majd a szervizt. Az Edit Security gomb alatt lehet a már em- 
lített széleskörű szolgáltatás engedélyeket kiosztani. 

(Lsd. előző ábra) 


Ha valamely külső szervizzel szeretnénk ugyanezt megten- 
ni, akkor azt először telepítenünk kell azon a szerveren, 
amelyiken a Csoportházirendet konfiguráljuk, vagy ha ezt 
nagyon nem szeretnénk, akkor telepítsük fel az 
Administration Tools Pack eszközt egy kliensre a követke- 
ző módon: 


WecszervernévoVAdmin$iSystem32VAdminpak .msi 


De megtehetjük ezt a szerver CD 386 mappájából is, a lé- 
nyeg hogy ezután az Active Directory Users and 
Computerst elindítva nyissuk meg a System Services részt 
a Csoportházirendből, ami immár mutatni fogja az adott 
gép szervizeit is, ergo behegeszthető a Csoportházirend- 
be is. Mi például, használunk külső tásemenedzsment prog- 
ramot, amely szerviz alapú, így megoldható, hogy minden 
kliens gép futtassa az adott szervizt kötelezően. 


A manualitás varázsa -— szerviz 
telepítés/eltávolítás 

Előfordulhat olyan eset, amikor nem lehetséges egy telepí- 
tőprogrammal szervizt készíteni az általunk kívánt alkalma- 
Zzásból, vagy éppen a telepítőprogram nem hajlandó le- 
szedni az adott szolgáltatást. Erre számtalan megoldás lé- 
tezik, a klasszikus már az NT4-nél is használható, a 
Resource Kit-ekben előforduló SrvAny.exe-től [4] a GUIl-n 
működő kényelmes Srvlnstw.exe-ig [5]. Működési elvüket 
tekintve azonban általában az Svchost.exe-re hasonlíta- 
nak. Elsőként beolvassák az alkalmazás elérési útvonalát, 
és paramétereit majd bejegyzik ezeket a regisztrációs 
adatbázisba a többi szerviz adatai közé. Ezután pl., amikor 
az SrvAny elindul, értesíti az SCM-et, arról hogy ez a szer- 
viz az ő asztala, majd saját (gyerek)processzekérnt futtatja 
az alkalmazást. Ezzel lehetséges lesz a leendő szervizt 
ugyanazzal a fiók engedéllyel és jogkörrel futtatni, mint ma- 
gát az SrvAny-t. Fontos különbség viszont, hogy az SrvAny 
nem tudja megosztani magát több processz számára, ha- 
nem minden egyes saját szervizének futtatásához külön 
példány szükséges önmagából. 


(Terveink szerint a következő részben a Windows Server 
2003 szervizeiről konkrétan, egyesével esik majd szó.) 
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A VVindowvws 


csomagtelepítője 


AZ UPDATE.EXE REJTELMEI 


Az Update.exe kissé rejtőzködő életmódot folytat: 


gyakran használjuk, mégis csak ritkán találkozunk 


vele közvetlenül. Az általa végzett feladat fontossága 


miatt azonban megérdemli a nagyobb figyelmet. 


Microsoft szándékai szerint a közeljövőben már 

csak két telepítőprogram fogja végezni az összes 

Windows komponens és javítócsomag, valamint 
az alkalmazások és azok kiegészítő komponenseinek tele- 
pítését. A két telepítő a jól ismert Windows Installer, amely 
az alkalmazás-komponensek telepítéséért felelős, és az 
Update.exe, amelynek segítségével a Service Pack-ok és 
a hibajavító csomagok rendszerbe építését végezhetjük el. 
Cikkünkben megvizsgáljuk a telepítőprogram működésé- 
nek részleteit, a telepíthető csomagok típusait, a telepítés 
folyamatát, a telepítési módokat és a csomagok belső 
szerkezetét is. 


A frissítőcsomagok típusai 

A szokásos frissítócsomagokat - legyen akár Service 
Pack, akár gyorsjavítás — a Microsoft általában önkicsoma- 
goló exe fájl formájában terjeszti, amelyek három jól elkü- 
löníthető funkciójú részből állnak. Az egyik rész maga a te- 
lepítőprogram, a másik a telepítés futásához szükséges 
kiegészítő fájlok (például az update.inf, amelyről később 
még szót ejtünk), végül pedig a csomag által hordozott 
,hasznos teher" (all-ek, végrehajtható fájlok vagy scriptek), 
amelyek be fognak épülni a rendszerbe. 

Lényegében mindössze két csomagtípust különböztethe- 
tünk meg: 

m gyorsjavítás (hotfix), amely általában egyetlen jól 
körülhatárolható funkcióval kapcsolatos hibajavítást 
tartalmaz 

mu Service Pack, amely az előző Service Pack, illetve 
az adott termékverzió megjelenése óta megjelent 
összes változtatást tartalmazza. 


A telepítés folyamata és 
visszatérési kódjai 

A javítócsomag tehát a legtöbb esetben egy exe fájl, ha ezt 
paraméterek nélkül indítjuk el, kimásolja a csomag tartal- 
mát egy ideiglenes könyvtárba, majd elindítja az 
Update.exe-t, ami elvégzi a csomag telepítését. 

Sok esetben szükség lehet arra, hogy a csomag kibontása 
után ,kézzel" indítsuk el az Update.exe-t, például azért, 
hogy még a telepítés előtt megvizsgálhassuk a csomag 


tartalmát, esetleg módosíthassuk a telepítést vezérlő konfi- 
gurációs fájlokat. (Nyilván sokan emlékeznek még a Win- 
dows NT 4.0 Service Pack-jaira, amelyeket az Internet Exp- 
lorer 5.5 verziójával együtt járó 128 bites titkosítási szint 
miatt, csak az Update.inf megfelelő módosítása után lehe- 
tett telepíteni.) 


A javítócsomagok telepítése vázlatosan az alábbi lépések- 
re tagolható: 
Mu az update.inf betöltése 
m naplófájl előkészítése 
Wu a csomag és a futó operációs rendszer kompatibilitá- 
sának ellenőrzése (a [Version] szekció alapján) 
u az update.inf alapján a telepíthető fájlok listájának 
összeállítása 
m az update.ver fájlban tárolt verzió, méret és hash in- 
formáció, és a rendszerben található fájlok adatainak 
összehasonlításával a ténylegesen telepítendő fájlok 
listájának összeállítása 
m expressz telepítés esetén a szükséges fájlok letölté- 
se 
mu ha szükséges (nem volt /N kapcsoló) a régi fájlok 
mentése és az eltávolításhoz szükséges információk 
rögzítése 
fájlok másolása 
registry értékek beállítása 
ideiglenes fájlok és könyvtárak törlése 
ha szükséges (a beállítást az update.inf tartalmazza) 
és a programnak megadott kapcsolóval le nem tiltot- 
tuk, a rendszer újraindítása 
mu a függőben lévő fájlcserék (Pending File Renames) 
elvégzése 


A következőkben részletesen megvizsgáljuk a kitömörítést, 
majd a telepítést vezérlő parancssori kapcsolókat. 
A kitömörítést vezérlő kapcsolók a következők: 
m /O - az állapotjelző ablak nem jelenik meg a kitömö- 
rítés alatt. 
m /X- kitömöríti a csomag tartalmát az Update.exe in- 
dítása nélkül (rákérdez a fájlok másolásának célmap- 


pájára). 











mM /X:cmappanév: - a megadott mappába bontja ki a 
csomagot, az Update.exe indítása nélkül 

m /U- nem kérdez rá a célmappa nevére (meg kell ad- 
nunk a /X, vagy a /X:-mappanév: kapcsolót) /X ese- 
tén a csomag véletlenszerűen generált nevű mappá- 
ba kerül. 


A kitömörítés után a csomag telepítését az Update.exe pa- 
rancssori kapcsolóival befolyásolhatjuk (a kapcsolók bár- 
melyike megadható az önkicsomagoló exe-nek is, az egy- 
szerűen továbbadja azokat a telepítőprogramnak, a kicso- 
magolás folyamatát nem módosítják). A lehetséges kap- 
csolók a következők: 

Mm /U- beavatkozás nélküli (unattended) telepítési mód. 
A telepítőprogram nem vár felhasználói beavatko- 
zást, a teljes folyamat az alapértelmezett értékek fel- 
használásával megy végbe, folyamatjelző tájékoztat 
az előrehaladásról 

mu /O - csendes (guiet) telepítési mód. Hasonló a be- 
avatkozás nélküli módhoz, de sem a folyamatjelző, 
sem az esetleges hibaüzenetek nem jelennek meg. 

mM /F - kényszerített újraindítás (force restart). A telepí- 
tés után minden futó alkalmazást bezárul, (a nem 
mentett fájlok elvesznek) és a rendszer újraindul. 

m /N- régi fájlok mentése és eltávolítási lehetőség nél- 
küli telepítés. 

m /O- OEM fájlok megerősítés nélküli felülírása. Normál 
telepítés során a számítógép gyártója által biztosított 
fájlok felülírására a telepítőprogram rákérdez, ezt tilt- 
hatjuk le a kapcsoló megadásával. (Felügyelet nélkü- 
li telepítési módok esetén a telepítő nem írja felül az 
OEM fájlokat, ha nem adjuk meg a /O kapcsolót.) 

m /Z- újraindítás nem szükséges (suppresses restart). 
Ezt a kapcsolót akkor érdemes használnunk, ha egy- 
más után több gyorsjavítást is telepítünk, ekkor ele- 
gendő csak az utolsó után újraindítani a rendszert. 

m /L- a telepített gyorsjavítások listázása. Ez a kapcsoló 
csak önállóan használható, a telepítőprogram a re- 
gistry megfelelő részének olvasásával készíti el a tele- 
pített gyorsjavítások listáját (a javítócsomagokhoz kap- 
csolódó registry kulcsokról később még szó lesz). 

mu /S:cmappanév: - a kapcsoló segítségével integrált 
telepítőkészletet készíthetünk, vagyis a csomag tar- 
talma az operációs rendszer telepítőkészletébe kerül, 
és azzal együtt telepíthető. 

mu /D:cmappanév: - megadhatjuk a régi fájlok menté- 
sére használt mappa nevét (csak Service Pack ese- 
tén használható). 

m /ER - kibővített visszatérési kódok. 


Ha a telepítőt batch fájlból indítjuk, lehetőség van a kapott 
visszatérési kódok értékelésére, és a numerikus kódtól füg- 
gő elágazások megadására is. Az ER kapcsoló használa- 
ta nélkül a következő visszatérési kódokat kaphatjuk: 
m 1603 (ERROR INSTALL FAILURE) - hiba történt a te- 
lepítés során. 
m 0 (ERROR SUCCESS) - sikeres telepítés. 
m 3010 (ERROR SUCCESS REBOOT. REGUIRED) - 
sikeres telepítés, újraindítás szükséges. 


Függőben hagyott fájlcserék 
(PRending File Renames) 

Ha a javítócsomag telepítését futó rendszerre (tehát nem 
operációs rendszer telepítőcsomagjába) végezzük, jó esély 
van rá, hogy a cserélendő fájlok között lesz olyan, amelyet a 
rendszer éppen nyitva tart, ezért nem lehet felülírni azokat. 
Ebben az esetben a csomagból származó fájl a PFR sorba 
kerül (ez egy registry kulcs), ami a következő rendszerindí- 
táskor cserélendő fájlok listáját tartalmazza. Ilyen esetben a 
telepítés csak a rendszer újraindítása után tekinthető befeje- 
Zettnek. A korábban említett visszatérési kód ad információt 
az újraindítás szükségességéről. 





Láncolás (OAchain) 

A Ochain technológia segítségével több gyorsjavítás (vagy 
Service Pack és gyorsjavítások) telepítése végezhető el 
egymás után egyetlen újraindítással (a PFR sor használa- 
tával). 


Verzióinformációk 

A csomagot alkotó dll-ek verzióinformációin kívül (ezeket 
az update. ver fájlban találjuk) maga a csomag is rendelke- 
zik verziószámmal. Telepítés után a verzióra vonatkozó in- 
formáció a registryben tárolódik, ha azonban még a telepí- 
tés előtt szeretnénk meghatározni a csomag verziószámát, 
kicsomagolás után az update.inf fájlban találhatjuk meg a 
keresett információt, de nem a [Version] (itt a célrendszer- 
re vonatkozó adatok vannak), hanem a [Strings] szekció- 
ban a BUILDTIMESTAMP kulcs alatt. Az érték a csomag 
készítési dátumából és idejéből képzett karakterlánc (pél- 
dául 20040102.141500). Ilyen módon igen egyszerű a kü- 
lönféle verziók összehasonlítása, és az újabb csomag kivá- 
lasztása. 


A frissítésekhez kapcsolódó 
registry kulcsok és értékek 
A telepítés során az Update.exe számos registry értéket 
hoz létre, amelyek dokumentálják a telepítést, eltárolják a 
telepített fájlokra vonatkozó adatokat, és információt szol- 
gáltatnak az eltávolítást végző folyamatnak. A frissítések 
telepítése során három registry területre kerülnek informá- 
ciók: 

mu Update szekció 
HKEY LOCAL MACHINEYSoftwareMicrosoftWpdatesY 


m Hotfix szekció 


HKEY LOCAL MACHINEVSoftwareMicrosoftWindowsNTYV 
b CurrentVersiontHotfixN 


mu Programok telepítése és törlése szekció (Add/ 
Remove Programs) 


HKEY LOCAL MACHINEVSOFTWAREMicrosoftWindowsYV 
$ CurrentVersionWninstall 


A Hotfix szekció csak az operációs rendszer javításaival 
kapcsolatban tárol adatokat, míg az Update szekcióban a 
felhasználói programok javításainak információit is megta- 
lálhatjuk. 

A Service Pack telepítések közben a telepítőprogram törli a 
korábban külön feltelepített gyorsjavítások adatait (a 
Service Pack eltávolítása helyreállítja a törölt értékeket). 


Az Update szekció 
m Összefoglaló információk (Summary information) 
Az összefoglaló információk a 


HKEY LOCAL MACHINEYSOoÍftwareMicrosoftWpdatesY 
$ [Termék nevejNISP verzió] VKBitátátátáttt 
registry kulcs alatti 


bejegyzésekben találhatók (a 


KBHHHHHHE a csomag által javított problémát leíró Tudásbá- 
zis (Knowledge Base) cikk száma). Az egyes bejegyzések, 
és azok tartalma az adott alkalmazás igényei szerint változ- 
hat. 
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A KB823980 gyorsjavítás összefoglaló 
információi a registryben 


m Fájl lista bejegyzések (File list keys) Az itt szereplő 
bejegyzések a csomagot alkotó egyes fájlokról tartal- 
maznak információt (név, létrehozási dátum, verzió, 
stb.). Fájl lista bejegyzések csak a gyorsjavításokhoz 
készülnek a Service Packok-hoz nem, mivel egy 
Service Pack összes fájljára vonatkozó információ je- 
lentősen megnövelné a registry méretét. A fájl lista 
bejegyzések a következő kulcs alatt találhatók: 


HKEY LOCAL MACHINEYSoftwareMicrosoftWPpdatest 
4 [Termék nevejNV[SP verzió] NKBétététttáttiNFilelist 


A Hotfix szekció 

A Hotfix szekciót csak az operációs rendszer frissítései 
használják (azok is egyre kevésbé), az itt szereplő kulcsok 
nagy része már egyáltalán nem használt. 


A Programok telepítése és törlése 
szekció 
Ez a szekció tárolja a rendszerbe telepített frissítések és 
gyorsjavítások eltávolításával kapcsolatos információkat. A 
Programok telepítése és törlése szekció a következő kul- 
csokat tárolja: 
mu Display Name - a Programok telepítése és törlése 
ablakban megjelenített név 
m Display Version - a frissítés verziószáma 
mu HelpLink - támogatási információk elérési útvonala 
mu NoModify — meghatározza, hogy a , Módosítás" gomb 
megjelenjen-e a grafikus felületen. 
u NoRepair - Meghatározza, hogy a , Javítás" gomb 
megjelenjen-e a , Támogatási információ" lapon. 
m Publisher - a közreadó vállalat neve. 


m Uninstall String — a karakterlánc által meghatározott 
program indítja a javítás eltávolítását. 

m URLInfoAbout - a , Támogatási információ" lapon a 
közreadó neve alatt megjelenő link. 


Telepítési módok 
Service Pack vagy gyorsjavítás telepítésekor két telepítési 
mód (és letöltendő telepítőcsomag) közül választhatunk: 

m Teljes telepítés (Ful!/ install) — teljes telepítés esetén 
maga a telepítőcsomag tartalmazza az összes szük- 
séges fájlt, így az Update.exe-nek minden helyben 
rendelkezésére áll, hogy a telepítést elvégezze. Ez a 
módszer ajánlható nagyobb számú gép esetén (és 
persze akkor, ha a letöltött csomagot vizsgálni vagy 
módosítani szeretnénk telepítés előtt). 

m Expressz telepítés (Express install) -— önálló gépek 
esetében takarékosabb módszer lehet az expressz 
telepítés, mivel ekkor az Update.exe a rendszer vizs- 
gálatával összeállítja a frissítendő fájlok listáját, és 
csak ezeket tölti le a Windows Update webhelyről. 


A két telepítési mód egyébként mindenben teljesen 
megegyező módon jár el, csak a csomag ,hasznos terhét" 
jelentő fájlok forrása különböző. 


Frissítések telepítése batch fájlok 
segítségével 

Batch fájlok segítségével könnyen megoldhatjuk több 
gyorsjavítás (vagy Service Pack és gyorsjavítások) együt- 
tes telepítését egyetlen újraindítással. 

Ha biztosak vagyunk benne, hogy szükség lesz újraindi- 
tásra (Service Pack telepítése után mindig kell), egyszerű 
dolgunk van: az update.exe , megjegyzi" a korábban kelet- 
kezett újraindítási igényeket. Az utolsó javítás telepítésekor 
nem használjuk a /Z kapcsolót, így ha ennél a telepítésnél 
éppen nem is lenne szükség újraindításra, a korábbiak 
alapján az Update.exe mégis kezdeményezni fogja azt, és 
végrehajtja az összes függőben lévő fájlcserét (Pending 
File Renames), 

CECHO OFF 

SETLOCAL 


REM A telepítőcsomagok helye 
SET SPMappa-D:NVSP2 


9SPMAPPAXVSP install.exe /Z /U 
9SPMAPPAXWPpdate A.exe /U 


Ha nem tudjuk előre, hogy szükséges-e az újraindítás, ak- 
kor az Update.exe visszatérési kódjait vizsgálva tisztázhat- 
juk a helyzetet. 


CECHO OFF 

SETLOCAL 

REM A telepítőcsomagok helye 
SET SPMappa-D:NSP2 


REM Ezt a változót használjuk az újraindítási 
REM igény tárolására, értéke kezdetben 0 (nincs 
REM újraindítás) 

SET Reboot-O 


9SPMappasWupdate A.exe /Z /U 
IF ERRORLEVEL 3010 SET Reboot-1 


9SPMappasYWupdate B.exe /Z /U 
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IF ERRORLEVEL 3010 SET Reboot-1 


9SPMappasNUpdate C.exe /Z /U 
IF ERRORLEVEL 3010 SET Reboot-1 


REM újraindítás szükséges? 

IF $RebootX--1 Shutdom /r 

A batch fájlban használt shutdown.exe a Windows XP ré- 
sze, de Windows 2000 esetében a Resource Kit-ből külön 
telepítendő. 


Az Update.exe-hez kapcsolódó fájlok 
A következőkben sorra vesszük a Service Pack-ok és 
gyorsjavítások telepítését végző, illetve vezérlő egyes fáj- 
lok funkcióit. 
m update.inf — a fájl az Update.exe által felhasznált in- 
formációk fő forrása. Tartalmazza frissíthető operá- 
ciós rendszer-verziókra vonakozó információkat, a 
másolandó fájlok és a módosítandó registry értékek 
listáját, a telepítés közben elvégzendő egyedi műve- 
letekre vonatkozó utasításokat 
mM update.ver - a telepítendő fájlok verzió, méret és 
hash információit tartalmazza 
w spunlnst.exe — a csomag eltávolítását végző program 
m spmsg.dil - a naplózást végző függvényeket tartal- 
mazza 
mu custom.dil (spcustom.dil) — a csomag telepítéséhez 
szükséges egyedi funkciókat megvalósító függvé- 
nyeket tartalmazza, a függvények meghívására vo- 
natkozó adatok az update.inf-ben találhatók 
m spnres.dil - erőforrás sztringeket tartalmazó dll 
m branches.inf — az ágak közötti hierarchikus kapcsola- 
tot definiálja 
u update RTMGDR.inf, update RTMOFE.inf - az 
update. inf fájl megfelelői több ágon végrehajtható te- 
lepítőócsomag esetén (lásd később). 
mu updatebr.inf - meghatározza az alapértelmezett 
ágat, a közös fájlok helyét, és az Update.exe ennek 
segítségével választja ki az adott ághoz tartozó 
update.inf — fájlt (update RTMGDR.inf "vagy 
update RTMOFE.inf) 


Naplófájlok 
Minden telepített Service Pack vagy gyorsjavítás létrehoz- 
za saját naplófájlját a Windows gyökérkönyvtárában 
(9ewindir96). A naplófájl nevét az update.inf fájl határozza 
meg, az InstallLogFileName változó a [Strings] szekció- 
ban szerepel. 
A naplófájlok tartalma az adott csomag tulajdonságaitól 
függően változhat, de általában tartalmazzák az alábbi in- 
formációkat: 

Wu parancssori paraméterek 

m függőben levő fájlcserék (Pending File Renames) a 
registryből 
a telepítés időpontjára és az egyes műveletek időtar- 
tamára vonatkozó adatok 
lemezterület felhasználás 
OEM fájlok vizsgálatának eredményei 
fájlmásolási műveletek 
registry műveletek 
a custom.dlil-ből végrehajtott folyamatok, és azok 
visszatérési kódjai 


Mappastruktúra 
A kitömörítés után keletkező mappastruktúra szempontjá- 
ból három különféle javítócsomaggal találkozhatunk. 
A legegyszerűbb struktúra mindössze két mappából áll, a 
gyökérből és az alatta létrejövő update mappából. Az 
update mappában találjuk az Update.exe, update.inf, 
update.ver, custom.dil, stb. fájlokat, a gyökérben pedig a 
telepítendő fájlok mellett az spuninst.exe-t, az spmsg.dll-t, 
és az spnres.dll-t. 
A duál módú javítócsomag két különböző operációs rend- 
szer verzió frissítését végezheti el (ilyennel csak Windows 
XP esetében találkozhatunk). Például a Windows XP RTM 
és a Windows XP SP1 frissítését elvégző duál módú javító- 
csomag a következő struktúrát hozza létre: 

mu gyökérmappa 
common (minakét verzióhoz használandó fájlok) 
RTM (az RTM verzióhoz használandó fájlok) 
SP1 (az SP1 verzióhoz használandó fájlok) 


A gyökérmappa tartalmazza azt a végrehajtható fájlt (pél- 
dául Xpspi1hfm.exe), amely meghatározza, hogy melyik 
verzióhoz használandó fájlokat telepítse az Update.exe. 

A több ágat támogató (Multi-Branch-Aware) frissítőócsoma- 
gok (csak Windows Server 2003-hoz) több telepítési hely- 
zet támogatására készültek, hasonlóan a duál módú cso- 
magokhoz. Ebben az esetben azonban a telepítendő fájlok 
GDR (General Distribution Release) és OFE (Hotfix) verzió- 
ként is megkülönböztetésre kerülnek. A GDR verzió a szé- 
les körben terjesztett (és tesztelt) kritikus fontosságú javítá- 
sokat tartalmazza, a Hotfix verzió pedig ezen felül, az 
egyes vállalati felhasználók speciális igényeinek megfele- 
lő, kisebb súlyú változtatásokat is. A telepítőprogram a 
rendszerben már megtalálható fájlok verzió-információinak 
elemzésével dönti el, hogy az adott gépen melyik csomag 
telepítését kell elvégeznie. 


A csomag a következő struktúrát hozza létre: 
mu gyökérmappa 
u update 
mu rtmgdr 
mM rtmafe 


A Windows Server 2003 SP1 megjelenése után SPi1gdr, és 
SPidfe mappa is lesz, tehát egyetlen javítócsomagban 
ugyanannak a fájlnak akár négy különböző verzióját is 
megtalálhatjuk. 

Az említett struktúráknak megfelelő javítócsomagokat talál- 
hatunk például az [1] címen (a Windows XP verzió duál, a 
Windows Server 2003 verzió pedig több ágat támogató 
csomag). 


SZERÉNYI LÁSZLÓ 
szerenyi .lamet.bu 


A cikkben szereplő URL-ek: 


(1] http; / support. microsoft.com,/ default aspx?scid-kb; 
tpen-us:82398085d-tech 
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Ami a hivatalos Microsoft 
tanfolyamokból kimaradt... 


EXCHANGE 2000/ EXCHANGE SERVER 2003 


Sorozatot indítunk, olyan témákról, amelyek kimaradtak 


vagy nem kellő részletességgel szerepelnek 


a hivatalos Microsoft tanfolyami anyagokban. Elsőként 


az Exchange Server £200393-mal kapcsolatos 


érdekességeket írjuk le, de az itt leírtak többsége 


az Exchange £2000-re is érvényes. 


bevezetőben szögezzük le: az alább szereplő té- 
mák nem kezdőknek szólnak! Akik nem értenek 
meg minden részletet, azoknak javasoljuk a 2400- 


as kódjelő ,Implementing and Managing Microsoft 
Exchange Server 2003" tanfolyam elvégzését. 


Csak a levelezéssel kapcsolatos 
rendszergazda eszközök telepítése 
Az Exchange kiszolgálót egy távoli munkaállomásról is le- 
het menedzselni az Exchange rendszergazda eszközök te- 
lepítése után. A telepítés során kiegé- 
szül az Active Directory Users and 
Computers eszköz azokkal a tulajdon- 
ságlapokkal és szolgáltatásokkal, 
amelyekkel a felhasználók, csoportok 
és kontaktobjektumok levelezéssel 
kapcsolatos tulajdonságait állíthatjuk, 
és települ az Exchange System 
Manager eszköz, amivel a levelező- 
rendszer paramétereit állíthatjuk be. 
Gyakran előadódik az a helyzet, hogy 
van egy olyan felhasználó-menedzs- 
menttel foglalkozó munkatársunk, aki- 
nek nincs szüksége az Exchange 
System Managerre, de az Active 
Directory Users and Computers esz- 
közt teljeskörűen használni szeretné. ezi 
Ilyenkor nem kell a teljes Exchange 

rendszergazda csomagot telepíteni, hanem elég a követ- 
kező fájlokat kimásolni a kiszolgálóról a munkaállomásra: 
Vorogram filestexchsrvrbinv 


Exchange 


nMaildsmx.d11 


. Escprint.d1l 
§ Address.d1ll 
h Exchmem.d11 


Ezek után regisztrálni kell ezeket a dll-eket: 
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Az Active Directory 
számos olyan , rejtett" 
szolgáltatást 


tartalmaz, amit 


rendszerünkben is 


kihasználhatunk. 


maildsmx.d11 
escprint.d11l 
address.d11l 
exchmem.d11 


regsvr32.exe 
regsvr32.exe 
regsvr32.exe 
regsvr32.exe 


Ezek után minden felhasználókkal kapcsolatos rendszer- 
gazdai feladatot el fog tudni végezni, természetesen felté- 
teleztük, hogy a Windows 2003 adminpak.msi már telepít- 
ve volt a munkaállomáson és munkatársunk rendelkezik a 
megfelelő jogosultságokkal. 


Több cég egy 

Exchange 2000/2003 
kiszolgálón 

Az Exchange 2000/2003 kiszolgáló le- 
hetőséget biztosít, hogy több e-mail 
tartomány levelezését megoldjuk se- 
gítségével, illetve a különböző tarto- 
mányokhoz tartozó felhasználók a 
címlistájukat nézve azt higgyék, hogy 
csak az ő cégük foglal helyet a kiszol- 
gálón. De vajon ezt hogyan lehet a 
legegyszerűbben elérni? 

A címjegyzékek és az e-mail címek 
generálásához LDAP lekérdezéseket 
kell megfogalmaznunk. De vajon az 
egyes cégek címezhető objektumait 
hogyan tudjuk szétválasztani egysze- 
rűen ilyen lekérdezések segítségével? Triviálisan az adód- 
na, hogy használjuk erre a , Company" bejegyzést. Ez a fel- 
használók és kontaktok esetében működik, de sajnos ha- 
mar rájövünk, hogy a csoport objektumnak nincsen 
, Company" tulajdonsága. Ha megnézzük egy csoport és 
egy felhasználó tulajdonságlapjait, gyakorlatilag csak egy 
közös jellemzőt találunk, ez pedig a csoporttagságuk 
(Member Of). 
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Exchange General] E-mailáddresses  ] Exchange ádvanced  ] 
General] Members MemberOf —]  Managedgy  ] 
Member of: 


e egzzszaezzz ei egz a a 
( MemberOf b Dialin ] Environment ] Sessions ] Remote control )] 
Terminal Services Profle  ]  COMr ] — ExchangeGeneral ] 
E-mail Addresses ] Exchange Features ] Exchange Advanced 
General ] Address ] Account ] Profle ]  Telephones ] Orgarizaton [ 


De vajon hogyan lehet erre a paraméterre LDAP lekérde- 
zést írni? Hiszen ez egy úgynevezett ,multivalued 
property", azaz több értéke is lehet: egy objektum több 
csoportnak is lehet tagja. 

A Find Exchange Recipients ablakban az Advanced fülön 
ki tudjuk választani a mezők (field) között a Member Of" 
paramétert, ehhez a kiválasztó feltétel érdekes módon az 
,]s (exactly)" annak ellenére, hogy a ,multi value" közül 
csak egyre kérdezünk rá. 

A Value mezőbe a keresett csoportobjektum sok neve kö- 
zül a distinguished name-et kell írni. Ezt legegyszerűbben 
az ADSIEdit eszközzel tudjuk megnézni, illetve onnan ki is 
tudjuk másolni: 


u zi2d 


CNzNonamebBt Properties 


Áltibute Edítor ] Security ] 


[7 Show mandatory attributes his view 
[7 Show optional attibutes 

[7 Show only attiibutes that have values 

Altibutes: 


en Unicode Sting NonameBt 


createTímeStamp UTC CodedTi..  2004.02.23. 21:41:05 
distinguishedN ame Distinguished .,, . CN:NonameBt 0U-Demt 
fromEnty Boolean TRUE 


String Attribute Edítor 5 


Áttribute: distinguishedName 





KENETET TESTET ose else 





Ezek után az LDAP lekérdezésünket már össze tudjuk 
állítani. 


Összefoglalva: ha több cég használ egy közös Exchange 
kiszolgálót, akkor hozzunk létre az egyes cégeknek meg- 
felelő csoportokat, és ezekbe a csoportokba rakjuk bele a 
céghez tartozó összes objektumot. Ilyen objektum lehet 
felhasználó, csoport, kontakt, de még nyilvános mappa is! 
Ezen csoportok birtokában a fenti módszerrel a ,Member 
Of" tulajdonság felhasználásával LDAP lekérdezéssel 
akár e-mail címek generálását végrehajtó Recipient 
Policy-t, akár globális címlistákat tudunk generálni. Sőt! 
Ha a cégeket szimbolizáló csoportokat biztonsági cso- 
portként vettük fel, akkor még a cégek objektumaira (pl.: 


mappák, címlisták) rögtön az alap hozzáférési jogosultsá- 
got is be tudjuk állítani. 

Kalandvágyók persze módosíthatják úgy a sémát, hogy az 
összes fontos objektumnak legyen , company" attribútuma, 
de ennek a megoldásnak az a nehézsége, hogy ettől még 
a rendszergazdai eszközök nem fognak rendelkezni felü- 
lettel ezen új paraméter módosítására, tehát még egy ilyen 
eszközt is ki kell fejlesztenünk. 


Törölt elemek visszaállítása 
bárhonnan 

Az Exchange adatbázisaiban lehetőség van arra, hogy a 
felhasználók által törölt elemek ténylegesen ne törlődjenek, 
hanem a normál mappastruktúrában nem látható, 
, dumpster"-nek nevezett kukából még visszaguberáljuk 
azokat egy bizonyos ideig. Ha ezt beállítottuk, akkor néz- 
zük meg, hogy egy jólnevelt felhasználó hogyan töröl egy 
levelet, és azt hogyan állíthatjuk vissza: 


1. felhasználó a törlendő elemet kijelölve lenyomja a 
, delete" gombot 

2. a levél bekerül a ,Törölt elemek" (Deleted Items) 
mappába 

3. a megfelelően beállított Outlookból való kilépéskor 
ürül a Törölt elemek mappa, vagy a felhasználó 
előbb-utóbb törli ezt a mappát. 


Ha ezt az elemet ezek után vissza akarja szerezni a fel- 
használó, akkor a Deleted Items/Törölt elemek mappában 
állva a Tools/Eszközök menü Recover Deleted Items.../Tö- 
rölt elemek visszaállítása... menü után megnyíló ablakban 
viszontláthatja a törölt levelét és visszaállíthatja azt. 


Mi van akkor, ha ,túlképzett" a felhasználónk, és nem a 
, Törölt elemek" mappa közbeiktatásával törli a leveleit, ha- 
nem SHIFT--Delete-tel rögtön az enyészetnek adja át azo- 
kat? Vajon ilyenkor bekerül-e a levelünk a dumpsterbe? 
Látszólag nem, legalábbis az Outlook az előbb leírt proce- 
dúra után a Törölt elemek mappából megnyitva nem mu- 
tatja ezt a törölt elemek között. Ha pedig nem a Törölt ele- 
mek mappában állva akarnánk megnyitni a dumpsterben 
levő elemek visszaállítását lehetővé tevő ablakot, akkor 
ezt nem tehetjük meg, mert ki van szürkítve az ezt lehető- 
vé tevő menü. 


A megoldás egy registry beállítás a kliens gépen: 


HKEY LOCAL MACHINEVSOFTWAREMicrosoftNExchangeV 
ClienttOptions : 
DumpsterAlwaysOn-1 (DWORD) 


Ha ezt beállítjuk, akkor a törölt elemeink visszaállítását le- 
hetővé tevő ablak bármelyik mappából megnyitható lesz 
az Outlook újraindítása után, és ezekből SHIFT--Delete-tel 
törölt leveleinket is viszontlátjuk. Sőt! Ugyanez a módszer 
nyilvános mappában állva az onnan törölt elemeket is 
visszaállíthatóvá teszi! Ezt a registry módosítást tehát min- 
denképpen érdemes elvégezni, mert így arra a gyakori 
kérdésre, hogy , Jaj, hova tűnt a tegnap véletlenül törölt le- 
velem????" akár telefonon instruálhatjuk felhasználóinkat a 
megoldással kapcsolatban. 
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Hogyan vehetjük hasznát az ANR 
névfeloldásnak? 

Mindenekelőtt mi is az az ANR? Ez az ,Ambiguous Name 
Resolution", azaz ,bizonytalan névfeloldás" kifejezésből 
származó rövidítés, az Active Directory azon keresési szol- 
gáltatása, melyben a keresendő szöveget az u.n. ANR att- 
ribútum-halmazba tartozó AD attribútumokban keresi, 
amelyek alaphelyzetben a következők: 

Display-Name 

Given-Name 

Legacy-Exchange-DN 
Physical-Delivery-Office-Name 

Proxy-Address 

RDN 

SAM-Account-Name 

Surname 


Az ANR keresést mindenki nap mint nap használja, hiszen 
amikor az Outlook címzési mezőibe begépelünk egy glo- 
bális címlistába tartozó személy e-mail címét, keresztne- 
vét, vezetéknevét vagy bejelentkezési nevét, vagy nevé- 
nek egy részletét, akkor ezt mind automatikusan beazono- 
sítja nekünk a címtár, és visszakapjuk az illető megjeleníté- 
si nevét. Ha nem lenne ANR, akkor a háttérben egy bonyo- 
lult lekérdezést kellene lefuttatnia az Outlooknak: 


Display-Name-szöveg VAGY Given-Name-szöveg VAGY.... 


Ráadásul, ha a keresési szöveg két szóból áll, akkor még 
bonyolultabb dolgot művel az AD: 


(Given-Name-első szó ÉS Surname-második szó) VAGY 
(Surname-első szó ÉS Given-Name-második szó) ... 


Látjuk tehát, hogy az ANR igen nagy szolgálatot tesz ne- 
künk, amit nemcsak az Outlook fejlesztői használtak ki 
nagy örömmel, hanem mi is kihasználhatunk. Első példa- 
ként a korábban említett címlisták lekérdezésénél, vagy 
bármely más LDAP keresésnél használhatjuk: 


át Find Custom Search — zlDl2d 


Ele Edit Wew Help 


Find: [Custom Search s] in [d Demo s] ! Browe.. J 


Custom Search . Advanced [ 





Enter LDAP guery: 













EzlJanOster 0 Contact 
£2 Marika Jánosi User 
£ János Vegetári User 





ni 
b 


[3 ítem(5) found 


Itt például csak annyira emlékeztünk a keresendő objek- 
tumról, hogy valami ,János" van benne. Ha a következő 
egyszerű lekérdezést adjuk meg a ,Custom Search" 
Advanced fülén, hogy: 


anr-jános 
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akkor pont a kívánt eredményt kapjuk, azaz megkapjuk 
Vegetári Jánost, Jánosi Marikát, és Jan Ostert is, akinek az 
e-mail címe janos$messze.ni. Szorgalmi feladatként azt is 
megteszi nekünk az AD, hogy a magyar ékezeteket figyel- 
men kívül hagyja, tehát a lekérdezés szempontjából 
mindegy, hogy jánost, vagy janost írunk. El lehet gondolni, 
milyen bonyolult lekérdezést kellett volna összeraknunk, ha 
ANR nélkül akartuk volna ugyanezt az eredményt... 

De hogy jön ide az Exchange? Egyrészt a korábban emlí- 
tett címlistáknál, vagy a lekérdezés-alapú disztribúciós 
csoportoknál használhatjuk, de arra is, hogy újabb attribú- 
tumok ANR halmazba vonásával a felhasználóknak még 
könnyebb címzési lehetőséget biztosítsunk. Gondoljunk ar- 
ra, hogy egy igazán nagy cégnél nem biztos, hogy név / 
szerint ismerjük az üzemi pszichiátert vagy az ügyeletes 
Help Desk munkatársat. Bár rá tudunk keresni a címlistake- 
resőnkben, de sokkal egyszerűbb lenne az, ha egyszerűen 
a felhasználó begépelhetné a címzett mezőbe azt, hogy 
, Pszichiáter", vagy azt, hogy , ügyeletes", és rögtön behe- 
lyettesítődne a tulajdonság mögötti felhasználó. 

Most már tudjuk, hogy ehhez elég az ANR halmazba be- 
rakni a Title (beosztás) mezőt, amit a Schema Manager 
eszközzel tudunk megtenni a legegyszerűbben. Ha rendel- 
kezünk a megfelelő jogosultságokkal, regisztráltuk a 
schmmgmt.dll-t, akkor ezt megtehetjük a title attribútum tu- 
lajdonságlapján: 


MEZ T zi 


General ) 


Éz title 


Description: Title 
Common Name: Me 





TT Allov this attribute to be shown in advanced view 

F éttíibute ís actíve 

[7 Index this attribute in the Active Directory 

[7 Ambiguous Name Hiesolution TANF) 

[7 Replicate this attibute to the Global Catalog 

7 éttribute ís copied when duplicating a user 

TT Index this attibute for containerized searches in the Active Directory 








box ] eme [/ Ar ] 








Az Ambiguous Name Resolution-hoz a pipát csak akkor 
engedi berakni, ha a bekeretezett másik kettő flag is be 
van pipálva. Ebből az is látszik, hogy az ANR halmazba 
tartozó attribútumokat egyrészt indexeli az AD, másrészt a 
globális katalógusba is replikálja, így csínján kell bánni ez- 
zel a lehetőséggel, hogy ne legyen túl nagy a AD adatbá- 
Zisa, illetve a replikációs forgalom. 


Hogyan nevezzük át a Custom- 
Attribute tulajdonságok neveit? 

Ha már a sémában turkálunk, akkor nézzük meg, hogy mit 
lehetne az ellen tenni, hogy a felhasználók és egyéb cí- 








mezhető objektumaink ,Exchange Advanced" tulajdon- 
ságlapján kitölthető u.n. egyedi attribútumainak (Custom 
Attribute) normális nevet adjunk a ,gyári" exten- 
sionAttribute1, extensionAttribute2, . helyett. Például 
ezeket a tulajdonságokat használhatjuk arra, hogy a TAJ 
számot, adószámot, vagy akár az illető lábméretét tároljuk. 
Ha több ilyet használunk, örök probléma lesz, hogy vajon 
a lábméretet kell írni az extensionAttribute1-be, vagy a TAJ 
számot? Hogy ezt elkerüljük, érdemes lenne átkeresztelni 
ezeket a tulajdonságneveket. 

Ehhez lépjünk be Schema Admins tagjaként és -— akár az 
ADSIEdit eszközben - a Schema partícióban keressük 
meg a CN-ms-Exch-Extension-Attribute-1 elemet. Keres- 
sük meg az IDAPDisplayName nevű tulajdonságát, és írjuk 
át a kívánt sokatmondó névre, például TAJszam. 





CN-ms-Exch-Extension-Attribute-1 Properties 


Attibute Edítor ] Security ] 


(7 Show mandatory attributes 
[7 Show optional attributes 
[7 Show only attributes that have values 





a DUD § an04a 
Í5tring attribute Edítor [B 
Attribute: IDAPDisplayN ame 

Value: 


[TASszam 
EZHEGSEB[//NRTE EL ÁGEa [Eoe] [/ecsreáte 


(Sajnos nem használhatunk sem szóközt, sem ékezetes 
karaktereket itt.) 





Ezek után a felhasználók egyedi tulajdonságai (Custom 
Attributes) között már az általunk adott néven szerepel ez 
a tulajdonság. Ha LDAP lekérdezésben, vagy akár az 
Exchange-ben található dialógusablak szerkesztőben 
(Details Templates) hivatkozni akarunk erre az átnevezett 
tulajdonságra, akkor már az általunk adott új nevet kell 
használnunk. 





Felhasználó Properties 


MemberOf ]  Diakin ] Object ] Security 


Published Certificates 

Environment ]/ Sessions [ Remote control ] Terminal Services Profile ] COM: 
Exchange General E-mail Addresses 

General ] Address ] Account ]/ Profle ] Telephones ] Organization 
Exchange Features Exchange Advanced 

Simple display name: 


PERE 


TT Hide from Exchange address lists 
IT Downgrade high priority mail bound for 2.400 


View and modify custom attributes Custom Attributes... I 
EMETTTTZTETTÉTTTTTE ESEN IZT 3 


Select an attribute and then click Edit. 






Attribute 


Tálszam 
extensionáttribute2 


autancinnátrihuta 7 





Hogyan válaszoljunk a rendszerüze- 
netekre? 

Az Exchange rendszerben különböző esetekben kapha- 
tunk magától a szervertől üzeneteket. Ezek legtöbbször ar- 
ra hívják fel a figyelmünket, hogy megtelt a postaládánk és 
szabadítsunk fel egy kis helyet. Ha egy ilyen levélre a sze- 
gény felhasználó válaszolni szeretne (pl. rimánkodni sze- 
retne a rendszergazdának, hogy növelje meg egy kicsit a 
postaládája méretét), akkor egy kézbesítési hibajelzést fog 
visszakapni, hogy nincs olyan felhasználó, hogy Rendszer- 
gazda (angol nyelvi beállítású kliensnél: System 
Administrator). Hogyan lehetne mégis azt elérni, hogy az 
ilyen válaszok eltaláljanak a tényleges rendszergazdához? 
Vizsgáljuk meg egy kicsit jobban egy ilyen rendszerüzenet 
feladóját! 





A postafiók mérete meghaladja a megengedett értéket. 








Címzett: 
Másolatot kap: 





A postafiók mérete meghaladta a rendszergazda által megadott egy vagy több 
határértéket. 
A postafiók mérete: 4434 KB. 


A nnatafiábot máratkodátnrásai 


Azt látjuk, hogy a Rendszergazdának (System Ad- 
ministratornak) az a címe, hogy Rendszergazda (System 
Administrator), és ennek a címnek az a típusa, hogy 
SYSTEM. Hát erre tényleg jogosan kapunk kézbesítési hi- 
bajelzést, hiszen ilyen című levelesládánk tényleg nincs. 
Viszont tudunk csinálni! 

Nyissuk meg az igazi rendszergazda felhasználói fiókját, 
és vegyünk fel az exchange-es e-mail címei közé egy ú.n. 
Custom Address típusút a mellékelt ábra szerint. Innentől 
kezdve ezek a rendszerüzenet-válaszok célhoz érnek! 


eaz rdzán dai] (kájEi 


Address ] 





E-mail address: 


[EVSTEM 


E-mail type: 





Természetesen a kliensek nyelvi beállításainak függvényé- 
ben több ilyen , rendszergazda" címet is definiálnunk kell. 


Soós TÍBOR 
soostaigjb.ba 
IOSOFT - Jobn Bryce Oktatóközpont 


Kírművelt emberfők, 
Microsoft minősítéssel 


AZ OKTATÁSI TÁMOGATÁSOK RENDSZERE 


A vezető informatikai cégek közül a Microsoft elsők 


között ismerte fel az informatikai termékekhez és tech- 


nológiákhoz kapcsolódó tudásanyag rendszerezésében 





rejlő előnyöket. Ennek megfelelően alakította ki oktatási 


és minősítési koncepcióját, amely napjainkra a világon 


mindenhol elismert egységes rendszert alkot és a kere- 


tében képzett, minősített szakemberek is keresettek 


és megbecsültek a hazai és nemzetközi munkaerőpiacon 


egyaránt. Sorozatunkban a Microsoft kiforrott, 


de jelenleg is fejlődő oktatási rendszerét mutatjuk be. 


Az állami támogatások rendszere 

Az állami támogatás egyik legfontosabb formája a szak- 
képzési hozzájárulás, melyet az Oktatási Minisztérium ren- 
delete alapján minden erre akkreditált intézménynél igény- 
be lehet venni. Természetesen a magyarországi oktatóköz- 
pontok mindegyike akkreditáltatta magát, így ez a támoga- 
tás minden hivatalos Microsoft oktatás résztvevőjét érinti. 
Az Oktatási Minisztérium - a saját munkavállalók részére 
szervezett szakképzéssel kapcsolatos, annak elszámolá- 
sának feltételeiről és az elszámolás szabályairól szóló 
32/2001 (IX. 14.) OM. rendelet alapján - biztosítja azt a le- 
hetőséget minden munkáltató számára, hogy az általa kifi- 
zetett éves bruttó munkabér 1,5 százalékát kitevő hozzájá- 
rulásából 0,5 százalékos részt (azaz a fizetendő járulék 
egyharmadát) saját munkavállalóinak a képzésére fordítsa. 


Azoknak akik ezzel a kedvezménnyel élni kívánnak, az 
alábbi feltételeket kell teljesíteniük: 
u A munkáltató és a munkavállaló között megkötött ta- 
nulmányi szerződés. 
mu Egy képzési szerződés az oktatási intézmény és a 
hallgató között (amennyiben ez nincs, egy nyilatko- 
Zat, hogy ezt a képzés kezdetéig megkötik). 
m Szolgáltatási szerződés az oktatási intézmény és a 
munkáltató között. 


A hivatalos Microsoft oktatóközpontok az alábbi dokumen- 
tumok díjmentes rendelkezésre bocsátásával járulnak hoz- 
zá a kedvezmény igénybevételéhez szükséges adminiszt- 
ráció hiánytalanságához: az akkreditációs tanúsítvány hite- 
les másolata, a központ Microsoft képzéseinek listája idő- 


beni elrendezésben. Ezen túl már csak egy egyszerű el- 
számolási kérelmet kell a munkáltatónak kitöltenie, ami az 
Oktatási Minisztérium oldaláról az interneten keresztül pil- 
lanatok alatt letölthető. A kedvezmény érvényesítéséhez az 
eddig felsorolt dokumentumokat a képzés kezdete előtt be 
kell adni a megyei vagy fővárosi szakképzési bizottsághoz, 
s a kedvezmény máris rendelkezésére áll. 


Microsoft támogatások 


TecbNet 

Az egyik legismertebb, díjmentesen látogatható Microsoft 
rendezvénysorozat. Ez egy konferencia jellegű, rendsze- 
resen jelentkező technikai esemény, amelyen mindig más 
és más témát feszegetnek a Microsoft szakemberei. Le- 
gyen szó egy új termék vagy technológia bevezetéséről, 
egy fejlesztői kérdéskörről; egy ilyen nyílt fórumon sokkal 
jobb lehetőség van személyesen megtárgyalni a kérdése- 
ket a tűzhöz legközelebb álló, elismert szakemberekkel, s 
első kézből származó információt szerezni. Ezeken a ren- 
dezvényeken a résztvevők olyan elektronikus és nyomta- 
tott anyagokhoz juthatnak, amik egyéb fórumokon nem 
elérhetőek. A rendezvény nevével fémjelzett internetes fó- 
rumok és levelezőlista pedig prompt lehetőség a kérdések 
megtárgyalására. 


MSDN 

További támogatás a Microsoft részéről az előfizetéses 
rendszerben terjesztett fejlesztői szoftvercsomag, az 
MSDN. Ebben a konstrukcióban az előfizető alacsony éves 
díj befizetésével egy teljes naptári éven át megkapja az 
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összes Microsoft szoftvert. Benne minden operációs rend- 
szerrel, alkalmazással minden platformra, ráadásul még 
egyéb nyelvi verziókhoz is hozzájuthat, ami szoftverfejlesz- 
tés során kompatibilitási szempontból nagy előny lehet. A 
csomag tartalmazza továbbá az összes készülő program 
BETA vagy RELEASE CANDIDATE változatait is, amelyek a 
fejlesztőknek és a rendszerépítőknek ugyancsak fontos 
előnyöket jelenthetnek. 


Geopolitikai helyzetünkből adódóan kis hazánknak volt 
egy plusz előnye az elmúlt néhány évben, és lesz az elkö- 
vetkezőkben is. Az ország nincs messze az Európai Uniós 
csatlakozástól. Nyugaton, az Egyesült Államokban és Eu- 
rópa immáron egyesült részein ezek a vizsgák komoly ér- 
tékelés eredményeképpen teljes értékű végzettségekként 
mutathatók fel. A csatlakozás után, a határok leomlásával a 
munkaerőpiac is kiszélesedik. A cégek dúskálhatnak a 
megfelelően képzett szakemberek között, s az állásokat 
azok nyerik el, akik nagyobb szakmai kompetenciát tudnak 
felmutatni. 


MS Press kiadványok 

A Microsoft Press a Microsoft hivatalos könyvkiadója, mely- 
nek kínálatában több száz, önálló tanulásra szánt informa- 
tikai szakkönyv szerepel. A kiadványok minden olyan szak- 
ember számára nélkülözhetetlenek, aki a dinamikusan fej- 
lődő számítástechnikai világban naprakész tudással sze- 
retne rendelkezni. A könyveket azok számára is ajánljuk, 
akik csak most ismerkednek a Microsoft termékekkel és 
technológiákkal, és szeretnének lépésről lépésre -— önálló 
tanulás útján -— ismereteket szerezni az operációs rendsze- 
rek, az irodai és webes alkalmazások, fejlesztés, hálózati 
és szerveroldali rendszerek témakörében. 

Készüljön fel a hivatalos vizsgákra! A Microsoft Press köny- 
vek nem csak kiválóan segítik a szakemberek mindennapi 
munkáját, hanem remekül kiegészítik a hivatalos Microsoft 
tanfolyamokat is. Számos kiadvány a hivatalos Microsoft 
vizsgákra való felkészülésben is segít. A kiadványok ideá- 
lisak lehetnek azok számára is, akik nem tudnak eljutni tan- 
folyamokra, és segítségükkel szeretnék az ismereteket el- 
sajátítani, illetve vizsgára felkészülni. 


A Microsoft Press kiadványok hivatalos, angol nyelvű szak- 
könyvek, ezért feldolgozásukhoz az angol nyelv legalább 
alapfokú, dokumentumolvasás-szintű ismerete szükséges. 
Sok kiadvány megjelent magyar nyelven is, különböző 
kiadók gondozásában, érdemes tehát a vásárlás előtt ala- 
posan körülnézni a szakkönyvpiacon. 

A Microsoft Press kiadványok szinte mindegyike tartalmaz 
egy vagy több CD-mellékletet, a témához kapcsolódó 
anyagokkal, gyakorlatokkal, elektronikus (webalapú) tana- 
nyaggal, videókkal, bemutatókkal. Sok szoftvertermékhez 
kapcsolódó könyv mellé magának a szoftvernek korlátozott 
ideig használható verzióját is adják, melyet otthon saját gé- 
pünkre is feltelepíthetünk. 

A Microsoft Press kiadványai közül néhány többféle kisze- 
relésben (ún. special, premium, de-luxe kiadás) is megje- 
lenik, ami azt jelenti, hogy több kiadvány, könyv, bónusz 
CD található egy csomagban. Ezek egyben általában ked- 
vezőbb árúak is, mint külön-külön. 


Microsoft Press sorozatok 

A könyvek többféle témakörben, többféle szinten, és kü- 
lönböző felhasználóknak, szakembereknek készülnek. A 
kiadónak sok standard sorozata is van, íme, néhány a tel- 
jesség igénye nélkül: 


STEP BY STEP 
Elsősorban kezdő felhasználók részére ajánlott ,bemelegíi- 
tő" kiadványok, irodai programok, operációs rendszerek és 
fejlesztőeszközök témakörökben. Magyar fordításban is 
sok megjelent (Lépésről-lépésre könyvek) közülük. 


RUNNING SOROZAT 


INSIDE-OUT SOROZAT 

Aki mindent alaposan és a részletekbe menően szeretne 
tudni az operációs rendszerek és az Office termékek lelki- 
világárólaazok részére ideálisak lehetnek ezen sorozat 
könyvei. 


TRAINING KIT KÖNYVEK 

Részletes, különböző felkészültségű szakembereknek szó- 
ló kiadványok, melyek az alapoktól a professzionális szin- 
tig, önálló tanulás útján segítik az ismeretanyag megszer- 
zését, és az egyes témák elsajátítását elméleti anyag, gya- 
korlatok, tippek és trükkök, ellenőrző kérdések és felmérő 
tesztek segítségével. Windows, szervertermékek és fej- 
lesztői témakörökben érhetőek el. A vizsgákra is jól hasz- 
nálhatóak. 


REN DSZERGAZDAI KIADVÁNYOK 

(POCKET CONSULTANT. ADMINISTRATOR 5 
COMPANION) 

Ez a témakör több sorozatot és kiadványt is magában fog- 
lal. A professzionális, gyakorlati szakemberek, rendszer- 
gazdák, adminisztrátorok, IT-szakemberek nélkülözhetet- 
len segédeszközei, melyek a mindennapos munkát, telepí- 
tést, konfigurálást, rendszergazdai teendők elvégzését se- 
gítik. Áttekinthető, gyorsan kereshető forma, CD-mellékle- 
ten hasznos segédprogramok. A kiadványok a vizsgákhoz 
való felkészülésben is segítenek. 


FEJLESZTŐI KIADVÁNYOK 

A különböző felkészültségű és programnyelveket, techno- 
lógiákat használó fejlesztők, programozók részére több so- 
rozat több száz kiadványát kínálja a Microsoft Press, a 
programozás alapjaitól az adatkezelésen át a komplex 
nagyvállalati alkalmazások fejlesztéséig. 


RESOURCE KIT-EK. REFERENCE LIBRARY 

Teljes körű, a legrészletesebb ismeretanyagot, professzio- 
nális szintű ismereteket és referenciákat tartalmazó több 
kötetes üzemeltetői enciklopédiák. Minden, amit az adott 
termékről tudni kell, CD-mellékleten számos hasznos 
rendszergazdai segédprogrammal, mintapéldával. 


VIZSGAFELKESZÍTŐ ANYAGOK (READINESS REVIEW) 
Kifejezetten a hivatalos Microsoft (MCP) vizsgára készülők- 
nek ajánlott, csak vizsgakérdéseket tartalmazó kézikönyv, 
részletes elemzésekkel, válaszokkal, tesztekkel, vizsgatip- 
pekkel. Windows 2000/2003 és szerver témakörökben ér- 
hető el. CD-mellékleten mintatesztekkel. 


A hivatalos Microsoft minősítések 
rendszere 


Okleveles Microsoft Minősítések 

A Microsoft szakmai minősítései segítenek a kezdő és ha- 
ladó szakemberek számára, hogy segítségükkel olyan hi- 
teles és objektív okmányhoz és minősítéshez juthassanak, 
melyek magas szintű, naprakész számítástechnikai szaktu- 
dásukat igazolják az adott témában a vállalatoknak. Azok 
az informatikai kereskedelmi cégek, amelyek Microsoft ter- 
mékeket és technológiákat használnak, valamint hivatalos 
Microsoft minősítésekkel rendelkező szakembereket alkal- 
maznak, részt vehetnek a Microsoft Certified Partner Prog- 
ramban és így teljes értékű Microsoft partnerekké válhat- 
nak. A Microsoft Certified Partnerek a Microsoft nyújtotta 


A Microsoft Press kiadványokról további információk 


a Microsoft Press weboldalán a 


http:///www.microsoft.com/ mspress címen olvashatók, 
ahol részletes keresési lehetőség segít a válogatásban, 
valamint a kiadványok tartalomjegyzéke, olvasói hozzá- 
szólások és mintafejezetek is megtalálhatóak. Az angol 
nyelvű Microsoft Press kiadványok a hivatalos oktatóköz- 
pontokon keresztül rendelhetők meg. A rendelési tudni- 
valókkal, valamint árakkal kapcsolatosan keressék l 


az oktatóközpontok értékesítéssel foglalkozó képviselőit. 


szakmai és marketingtámogatások segítségével sikeres és 
nemzetközi szinten is elismert vállalatokká fejlődhetnek. 

A Microsoft a vállalati partneri programon belül további 
speciális minősítések megszerzését is lehetővé teszi, ilyen 
például a Microsoft Gold Certified Partner, illetve az oktatá- 
si tevékenységgel foglalkozni kívánó partnercégek számá- 
ra a Hivatalos Microsoft Oktatóközpont (Certified Technical 
Education Center, CTEC) program. 


További információk: 


http./ /members.microsoft.com/ partner/ partnering/ 


Okleveles Microsoft szakértő minősítések 

Az Okleveles Microsoft szakértő (Microsoft Certified 
Professional, MCP) minősítés a legjobb eszköz Microsoft 
termékekkel és megoldásokkal foglalkozó számítástechni- 
kai szakemberek, informatikusok tudásának mérésére. Se- 
gítségével a legjobb szakemberek elnyerhetik a megérde- 
melt, nemzetközi elismertséget. A minősítések az Európai 
Unióban és a tengerentúlon is egyre több állás betöltésé- 
nek feltételei. A vizsgák letételét ajánljuk rendszergazdák- 
nak, rendszermérnököknek, fejlesztőknek, és minden szá- 
mítástechnikai szakembernek, aki növelni szeretné elhe- 
lyezkedési esélyeit itthon és külföldön, és azoknak, akik 
szeretnének hivatalos minősítést szerezni szakterületüknek 
megfelelő számítástechnikai tudásukról. 


A megszerezhető oklevélfajták 


Okleveles Microsoft termékspecialista 

(Microsoft Certified Professional, MCP) 

Alapos ismeretekkel rendelkezik legalább egy Microsoft 
termékről. Ezenkívül további vizsgákkal bizonyíthatja jár- 
tasságát más szervertermékek, fejlesztői eszközök és al- 
kalmazások területén. 


Okleveles Microsoft rendszeradminisztrátor 
(Microsoft Certified System Administrator, 
MCSA) 

Magas szinten ért Microsoft Windows 2000-re és/vagy 
Windows Server 2003-ra és épülő kisvállalati rendszerek 
létrehozásához, üzemeltetéséhez karbantartásához. A mi- 
nősítésnek egy speciális fajtája az 
MCSA-Security minősítés, melynek el- 
nyerői Windows 2000-re, illetve Windows 
2003-ra épülő biztonsági rendszerek be- 
vezetésében és üzemeltetésében is jár- 
tasak. 

A minősítések egy másik, speciális fajtá- 
ja az MCSA4Messaging, amely cím el- 
nyerői az Exchange Server 2000 vagy 


ban járatosak. 


Okleveles Rendszermérnök 
(Microsoft Certified System 
Engineer, MCSE) 

! . Magas szinten ért a Microsoft Windows 
2000-re és/vagy Windows Server 2003- 
ra és Microsoft szervertermékekre épülő, 
összetett információs rendszerek terve- 
zéséhez, bevezetéséhez, üzemeltetéséhez, karbantartá- 
sához és támogatásához. A minősítésnek egy speciális 
fajtája az MCSE4-Security minősítés, melynek elnyerői 
Windows 2000-re illetve Windows 2003-ra épülő bizton- 
sági rendszerek bevezetésében és üzemeltetésében is 
jártasak. 

A minősítések egy másik, speciális fajtája az MCSE - 
Messaging, amely cím elnyerői az Exchange Server 2000 
vagy 2003 üzemeltetésében, és erre épülő nagyvállalati 
infrastruktúrának kialakításában, tervezésében járatosak. 





Okleveles Adatbázis Adminisztrátor 

(Microsoft Certified Databasec-Administrator, 
MCDBA) 

Magas szinten ért a Microsoft SOL Server termékekhez, 
SOL környezetű adatbázisok tervezéséhez, adminisztrá- 
ciójához, telepítéséhez és optimalizálásához, valamint az 
ezekhez szükséges Windows 2000 vagy Windows Server 
2003 környezet üzemeltetéséhez. 


Okleveles Alkalmazásfejlesztő BI 

(Microsoft Certified Application Developer, 
MCAD) 

Magas szinten ért Windows és webalapú szoftveralkalma- 
zások fejlesztéséhez, teszteléséhez, bevezetéséhez és 
karbantartásához Microsoft .NET platformon, Visual Studio 
.NET fejlesztőeszközökkel. 
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Okleveles Fejlesztő 

(Microsoft Certified Solution Developer, 
MCSD.NET) 

Magas szinten ért üzleti szoftvermegoldások tervezésé- 
hez, elemzéséhez, alkalmazások fejlesztéséhez, tesztelé- 
séhez, bevezetéséhez és karbantartásához Microsoft fej- 
lesztőeszközökkel, Microsoft technológiák és platformok 
felhasználásával. A minősítés jelenleg mind a hagyomá- 
nyos, mind a Visual Studio .NET alapú vizsgákból összeál- 
lítható, de a későbbiekben a .NET alapú minősítés kizáró- 
lagossága várható. 


Okleveles Microsoft Trainer 

(Microsoft Certified Trainer, MCT) 

Hivatalos Microsoft Oktatóközpontokban (MSCTEC), vala- 
mint a Microsoft oktatási rendezvényeken oktathat. Felté- 
tel az MCSE, MCSD vagy MCDBA mi- 
nősítés, valamint speciális készség- 
fejlesztő tréningek és tesztek sikeres 
teljesítése. A Microsoft trénereknek 
évente kell megújítaniuk szerződésü- 
ket és minősítésüket. Ehhez a Micro- 
soft által előírt oktatási és technikai 
felkészültségi kreditrendszernek (to- 
vábbképzéseken való részvétel, taní- 
tott órák száma, stb...) is meg kell 
megfelelniük. 


A minősítésekkel járó előnyök 

A Microsoft minősítések bizonyítják, hogy Ön szakmailag 
olyan magas szintű ismeretekkel rendelkezik, hogy sikere- 
sen és megbízhatóan képes bevezetni Microsoft üzleti 
megoldásokat, vagy adhat tanácsokat vállalatának vagy 
ügyfelének. A minősítésekkel járó közvetlen és közvetett 
előnyök és azok nagysága a megszerzett minősítés nagy- 
ságától (fokozattól) függ: 


Közvetlen előnyök 

m Az adott minősítést igazoló hivatalos tárgyak (kitűző, 
névkártya, oklevél). 

m Ingyenes hozzáférés a vizsgázott szakembereknek 
fenntartott privát weboldalon keresztül a Microsoft 
legfrissebb technikai és termékinformációihoz. 

mum A minősítéssel megszerzett Microsoft logók elérhető- 
sége és használata adott kereteken belül. 

u Ingyenes hozzáférés a Microsoft MCP Online 
Magazine-hoz, valamint egyéb, minősítésspecifikus 
számítástechnikai kiadványokhoz. 

mu A megszerzett minősítéstől függően ingyenes vagy 
kedvezményes meghívások itthoni és külföldi konfe- 
renciákra, tanulmányutakra, rendezvényekre. 

mu A megszerzett minősítéstől függő mértékű kedvez- 
ményes előfizetés a havonta megjelenő TechNet, 
TechNetPlus, MSDN szoftver- és információs CD- 
csomagra, melyek segítségével hozzájuthat a 
legújabb szoftvertermékekhez és termékbétákhoz, 
szervizcsomagokhoz és információkhoz. 

u Ingyenes vagy kedvezményes részvétel a Microsoft 
Magyarország egyes rendezvényein. 


6 


A Microsoft vizsgák 
nem könnyűek. 
Szánjon elég időt 


a felkészülésre! 


Közvetett előnyök 

m Az elhelyezkedési esélyek növekedése. 
Cégen belüli és nemzetközi elismertség. 
Karrierlehetőségek itthon és külföldön. 
Kiemelt kereseti lehetőség. 
Ingyenes vagy kedvezményes meghívások itthoni és 
külföldi konferenciákra, tanulmányutakra, rendezvé- 
nyekre. 
u Ingyenes vagy kedvezményes továbbképzések, ter- 

mékek vagy szolgáltatások igénybevétele. 


Microsoft vizsgalehetőségek 


A vizsgák felépítése 

A Microsoft kínálatában több mint negyven különböző 
technikai vizsga szerepel. A vizsgákat a Hivatalos Micro- 
soft Oktatóközpontok vizsgaközpont- 
jaiban tehetik le az érdeklődők. Vizs- 
gát tenni tanfolyam elvégzése nélkül 
is lehet, de preferáljuk a vizsga előtt 
az ahhoz kapcsolódó hivatalos Micro- 
soft kurzus elvégzését. Mind a felké- 
szülés, mind pedig a vizsgák viszony- 
lag nagy anyagi befektetéssel járnak, 
de ezek idővel többszörösen megté- 
rülnek! 

Az informatikai cégek érdeke, hogy 
magasan kvalifikált szakembereket al- 
kalmazzanak, és támogassák azok képzését, továbbkép- 
zését, vizsgáztatását, ezért mindenképpen előnyt jelent, 
ha valaki aktívan vagy pályakezdőként már dolgozik vala- 
milyen számítástechnikai munkakörben. A cégek így támo- 
gatni tudják az alkalmazott felkészülését mind anyagi, 
mind erkölcsi, mind pedig gyakorlatszerzési szempontból. 
Amennyiben erre nincs lehetőség, az első vizsgákat és az 
azokra való felkészülést magánúton, az olcsóbb Microsoft 
Press önálló tanulást segítő kiadványainak alapján és az 
online tanfolyamok segítségével oldhatjuk meg. A sikeres 
vizsgát, vizsgákat követően, zsebünkben a minősítéssel 
már könnyebben elhelyezkedhetünk és tovább képeztet- 
hetjük magunkat. 

A vizsgák nem könnyűek. A felmérések szerint a hivatalos 
Microsoft vizsgák kb. 60 százaléka sikeres. Ettől függetle- 
nül ne szegje kedvét, ha elsőre nem sikerül a vizsgája, hisz 
minden tesztből még többet tud meg a témáról és arról, mi- 
lyen területeken kell még ismereteit bővíteni. Szánjon minél 
több időt és lehetőséget a felkészülésre! 


A vizsgák számítógép előtt zajlanak és a Microsoft által 
összeállított tesztkérdésekből állnak. Legtöbb esetben ez 
feleletválasztós kérdéseket jelent, vagyis több válaszból 
kell kiválasztanunk a helyes választ vagy válaszokat. A 
Microsoft egyre inkább törekszik olyan vizsgák kifejleszté- 
sére, melyek valósághű állapotokat és helyzeteket tükröz- 
nek, ezért a legtöbb teszt számos problémamegoldásos, 
szimulációs és más interaktív feladatot is tartalmaz. A vizs- 
gák angol nyelven zajlanak, ezért az angol nyelv olvasás- 
szintű (legalább alapfokú) ismerete elengedhetetlen. Igény 
szerint egyes vizsgák más világnyelveken (németül, ola- 
szul, franciául, stb.) is elérhetőek (magyarul egyelőre saj- 
nos nem), de ekkor az adott nyelvű operációs rendszer 


mv 
o 


környezetével kell dolgoznunk a vizsgakérdések megvála- 
szolása során. 

A Microsoft vizsgák zárt könyvesek, vagyis semmiféle 
elektronikus vagy papíralapú segédanyagot (beleértve a 
szótárakat is!), eszközt nem lehet használni. Kivételt ké- 
pezhetnek a nem-programozható számológépek, valamint 
a vizsgaközpont által biztosított írótáblák 

A tesztkérdések összetételének, számának, a rendelke- 
zésre álló időnek, valamint a sikeres vizsgához szükséges 
pontszámnak a meghatározása, valamint ezek bármikor 
történő változtatása a Microsoft jogköre. A tesztek elején 
általában információt kapunk ezen paraméterekről. Általá- 
nosságban, a tesztek típusától és fajtájától függően 50-70 
kérdés és ehhez kapcsolódóan 135-240 perc áll rendelke- 
zésünkre, a szükséges pontszám 550-890 között mozog 
(1000 pontból) teszttől függően. A teszteredményt szinte 
minden tesztnél (kivéve az ún. bétateszteket) azonnal 
megtudjuk. (Megjegyzés: a legtöbb teszt esetében a Mic- 
rosoft biztonsági okokból már nem adja meg a szükséges 
és elért pontszámot, ezért csak egy sikerült/nem sikerült 
eredményt kapunk). 


A tesztek báromféle típusúak lebetnek felépítésük- 

tól függően: 
A hagyományos tesztek esetében a vizsgakérdések 
között lehetőségünk van ugrálni, megjelölni, illetve a 
már megválaszolt kérdésre visszatérni és a válaszon 
módosítani. A teszt pontozása lehet súlyozott és sú- 
lyozatlan. A rendelkezésre álló idő letelte után a meg- 
válaszolt kérdések alapján értékel a számítógép. 
Az adaptív tesztek esetében a kérdések között nincs 
lehetőség ugrálni; addig nem tudunk továbblépni a 
következő kérdésre, amíg az előzőre nem válaszol- 
tunk. A kérdések száma az elrontott válaszoktól füg- 
gően változó. Erre a típusra hosszabb időt adnak. 
Megjegyezzük, hogy a Microsoft ritkán alkalmazza 
ezt a típust. 
A kombinált teszt során a kérdéssor téma, illetve 
feladat szerinti szakaszokra van osztva. A szakaszo- 
kon belül hagyományos típusú a teszt. A szakaszból 
kilépve a gép értékel és ezt követően ezen kérdések- 
re már nem tudunk visszatérni. Legtöbb esetben min- 
den szakaszt sikeresen kell teljesíteni, hogy a teljes 
vizsga eredményes legyen. Ezt a típust hosszabb 
tesztek esetében, tervezős/esettanulmányos vizs- 
gáknál, valamint az összetettebb, minősítést frissítő 
(upgrade) vizsgáknál alkalmazzák. 


A vizsgákat kódszámukkal és nevükkel azonosítjuk. Az 
éles Microsoft vizsgák 070 (esetleg 076) sorszámmal kez- 
dődnek, majd ezt követi a háromjegyű vizsgaazonosító. 
(pl. 070-270) 


http:/ / www.microsoft.com/ traincert/ mepexams/ default.asp 
www.microsoft.com/ hun/ oktaj, 
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Jelszó-csata 


A Microsoft állásfoglalása a Microsoft Office Vord dokumentumok 


jelszavaival kapcsolatban. 


Néhány újságcikk a közelmúltban megkérdőjelezte a Mic- 
rosoft Office Word dokumentumok módosításának korláto- 
zására használt jelszavak hatékonyságát és biztonságos- 
ságát. A Microsoft ezekre válaszul a 


http: //support .microsoft . com/ ? id-822924 


címen hozta nyilvánosságra állásfoglalását az alábbi ma- 
gyarázatokkal kiegészítve: 

mA Microsoft Office Word dokumentumok módosításá- 
nak pusztán jelszóval, titkosítás nélkül való korlátozása 
nem biztonsági funkció, célja csupán az, hogy 
megakadályozza a dokumentumok véletlen megvál- 
toztatását. 

u A Wordben a jelszavas védelem csak akkor biztonsá- 
gos, ha megfelelő titkosító eszközökkel együtt hasz- 
nálják. A Word dokumentumok elérését korlátozó fájl- 
szintű titkosítás a Biztonság párbeszédpanel Speciális 
gombjának megnyomása után megjelenő titkosítási 
módszerek közül választható ki (Fájl I! Mentés másként 
I Eszközök I Biztonsági beállítások menüpont). 

m Az űrlapvédelmi és a , módosítási" jelszavak nem alkal- 
maznak titkosítást, de a , megnyitási" jelszavak igen. 


Microsoft Offic 


m Ha a felhasználók az információk megosztásához rész- 
letesen beállítható, szigorú védelmet szeretnének alkal- 
mazni, a Microsoft a Word 2003 programba beépített 
Tartalomvédelem összetevő használatát ajánlja. 

A Word 2003 biztonsági jellemzőinek bemutatása megta- 
lálható az Office Online webhelyen: 


http://office.microsofít.com/training/Training.asp 
x?AssetID-RPO104259010338CTT-680O0rigin-RCO10425851033 


További, általános jellegű tudnivalók az Office 2003 biz- 
tonsági jellemzőiről: 


http: //www.microsoft.com/office/ork/2003/seven/ 
default.htm 


További információ a Tartalomvédelem összetevőiről: 


http: //www.microsoft . com/office/ork/2003/six/ch20 
/default.htm, 


valamint: 
http: //www.microsoft . com/technet/treeview/default 


. asp?ur1-/technet/prodtechnol/office/office2003/ 
plan/ofO3irm.asp 


e Visio 2003 — 


magyar nyelven is 





A Microsoft Office Visio e2O 
zatban is megvásárolható, 





A Microsoft Office Visio 2003 ábrakészítő eszköz, Standard 
és Professional verziókból áll. A Standard változat az átla- 
gos üzleti felhasználóknak szól, a Visio Professional az IT- 
szakembereknek. A Visio 2003 a korábbi verziókhoz ké- 
pest számos kényelmi funkcióval gazdagodott: egysze- 
rűbb lett az alakzatok elforgatása, bővültek a formázási le- 
hetőségek, digitális szabadkézi eszközök vehetők igény- 
be, új sablonok segítségével ,ötletbörze diagramok" és 
számítógépes rackek diagramjai készíthetők el, ahol kör- 
nyezetérzékeny online súgó is segítséget nyújt. Módot ad 
egy XML-en alapuló képi szabvány, az SVG (Scalable 
Vector Graphics) formátumba történő exportálásra és az 
abból történő importálásra is. Új csoportmunka-funkciókat 
is tartalmaz: lehetőséget ad véleményezői módban történő 
használatra, amelyben több véleményező kiegészítheti 
megjegyzéseivel, visszajelzéseivel a fájlt anélkül, hogy az 
hatással volna az eredetileg elkészített munka egészére. A 
,haladók" a Visual Basic for Applications szerkesztőprog- 
rammal webszolgáltatásokhoz kapcsolhatják az alakzato- 
kat és az eseményeket, és a PIlA-k (Primary Interop 
Assembly) segítségével kezelt programkóddal írt beépülő 
modulokat építhetnek az ábrákba. A Visio Professional se- 


0 





03 februártól már magyar nyelvű válto- 
így összesen már 17 nyelven elérhető. 


gítségével elkészíthető a Microsoft SOL Server és 
Access adatbázisok dokumentációja. Létrehozható a 
Visual Studio. NET. fejlesztési projektek UML-diagramja, 
a Visio támogatja a Visual Basic .NET és a Ctt nyelven 
megírt beépülő modulokat, és az XML webszolgáltatásokat 
támogató kiadásokat is képes használni. Makro-rögzítőt és 
beépített VBA-szerkesztőt is tartalmaz. Megtervezhetők, il- 
letve dokumentálhatók vele az üzleti folyamatok, majd a fo- 
lyamat adatai ODX vagy BPEL (egy XML folyamatszab- 
vány) segítségével automatizálás végett megoszthatók a 
BizTalk Serverrel. A Visio Professional segítségével doku- 
mentálható és megtervezhető egy adott szervezet Active 
Directory címtár-szolgáltatási topológiája, a bevezetés és 
az áttérés megtervezésének részeként. 

A Shape Studioval alaktárak hozhatók létre. A szoftverfej- 
lesztő készlet (SDK) az egyéni alkalmazások létrehozását 
segítő minta programkódot, eszközöket, dokumentációt és 
PIA-kat tartalmaz. 


http: //www.microsoft . com/hun/office/preview/visio 
2003.mspx 
http: //www.microsoft . com/hun/office/visio 
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A MAN-IN-THE-MIDDLE TÁMADÁS 


Hadd mutassam be régi-új rovatomat. A Dn Watson nem 


más, mint az a rovat, amelyből 2000-ben az egész 


TechNet magazin kifejlődött. Oda térek vissza most, 


ahonnan egész , írói munkásságorm" elindult: egy havilap 





hátsó fertályán, az érdekességek rovatban leírom, amivel 


éppen foglalkozom. Ma már azt mondanánk rá: BL OG. 


Első blogom azzal az emberrel foglalkozik, aki középen áll. 


Microsoft nemrégiben kiadott egy négynapos 

PKI tananyagot, emellett már lassan három éve 

nyomja az IPSec-et - amit végül a kutya sem 
használ. Minek az nekünk? Hogyan is lenne képes bárki 
beékelődni két kommunikáló fél közé kapcsolt (switchelt) 
hálózaton? Most érdekes fordulat történt: az események- 
nek elébe menve megjelent egy olyan tananyag is, ami a 
legváltozatosabb hackertechnikákat mutatja be működés 
közben. Ebből ragadtam ki az elvetemült Man-in-the- 
middle támadást. 
Az ember, aki középen áll, minden rajta átmenő hálózati 
forgalmat lehallgat, sőt, adott esetben meg is hamisítja azt. 
Hol találunk switchelt hálózatban olyan pontokat, ahol ez a 
támadástípus megfelelően kivitelezhető? Az útválasztókon 
(router). Ha abból indulunk ki, hogy egy router-hardveren 
nem fut sem a Windows, sem a Linux, sem semmilyen ,ér- 
telmes" operációs rendszer, arra a következtetésre jutha- 
tunk, hogy nincs olyan pont a hálózatban, ahol egy közép- 
ső ember minden forgalmat lehallgathatna, meghamisíthat- 
na. Hacsak ki nem cseréli az egyik routert. Tehát nincs mi- 
től félnünk. És a snifferek? 
Tudjuk, mi az a Network Monitor, azt is tudjuk, hogy a pén- 
Zzes változata elvileg lehetővé tenné, hogy egy teljes háló- 
zati szegmens forgalmát elkapjuk és elemezzük 
(promiszkusz üzemmód). Ha a hálózatunk ma is vékony 
koax kábel, vagy hubbal összepókozott UTP lenne. Ezeket 
a technológiákat azonban már öt éve lecserélte mindenki 
kapcsolt Ethernetre (switch), amelyiknek jellemzője, hogy 
az eredeti Ethernet-koncepciót megcsúfolva az üzenetszó- 
rásos csatornát egy olyan modellel váltja fel, ahol a kom- 
munikáló felek pont-pont kapcsolatban állnak egymással 
(legalábbis unicast esetén). Itt a NetMon, az Ethereal és 
társai nem rúgnak idegen labdába. 
És mégis baj van! 


Hogy kerüljünk középre? 

Már régen érdekelt a probléma, hogy hogyan is lehet kivi- 
telezni egy ilyen támadást. Annak kapcsán gondolkodtam 
el, hogy a PKI-rendszerek alapja az x.509 tanúsítvány, amit 


egy külső, megbízhatónak tekintett harmadik fél 
(Certificate Authority) digitális aláírással lát el annak érde- 
kében, hogy ne kelljen félni a publikus kulcs megváltozá- 
sától. Tehát ez valós lehetőség, ha már egy egész iparág 
retteg tőle. 
Kitaláltam egy saját eljárást (ahogy azt Móricka elképzeli), 
ami azon alapult, hogy ha egy fizikai hálózaton külön logi- 
kai IP-alhálózatokat hozunk létre, az azokon található gé- 
pek csak egy alapértelmezett átjáró (default gateway) se- 
gítségével kommunikálhatnak egymással. Tehát a megol- 
dás kulcsa, hogy a támadott alhálózatban minden gép kü- 
lön IP-hálózatra kerüljön, amelyek között az én gépem az 
átjáró. Ezt az esetleg meglévő DHCP-kiszolgáló lelövésé- 
vel (Denial of Service), és egy saját, furfangos DHCP 
üzembeállításával gondoltam megvalósítani. Sajnos Móric- 
ka elmélete nagyon nehezen ültethető át a gyakorlatba, és 
ennek sok oka van, kezdve az eredeti DHCP-kiszolgáló 
biztonságos , megölésétől" addig, hogy statikus IP-címmel 
rendelkező masinákra ez a bűbáj nem hat. 
Az igazi megoldást ugyanis az ARP-protokoll adja a ke- 
zünkbe. Hallottak már a Gratious ARP-ről? Ez az a csomag, 
amit új IP-cím felvételekor minden gép szétküld a hálózat- 
ban (broadcast), mégpedig kettős céllal: 

m megállapítani, hogy az IP-címet használja-e már 

valaki 
u ha még nem használt a cím, az összes többi gép 
ARP-cache bejegyzését frissíteni (ha van mit) 


Most nem részletezném jobban az ARP-t, arra való a 
TCP/IP tanfolyam. De felhívnám a figyelmet a második 
pontra: mindenféle azonosítás (autentikáció) nélkül képe- 
sek lehetünk más, idegen gépek (Windowsok, Linuxok, 
nyomtatók, kólaautomaták és pacemakerek) ARP-táblájá- 
nak módosítására! 

Nem is nehéz ez. Az alábbi ábrán két kommunikáló felet 
láthatunk. Az A jelű gép MAC-addresse az egyszerű felis- 
merhetőség érdekében legyen AA-AA-AA-AA-AA-AA, míg 
a B 6 jelűé BB-BB-BB-BB-BB-BB.  IP-címeik pedig 
172.16.0.100 (A gép) és 172.16.0.200 (B gép). 
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Miután A és B gép felvette egymással IP-n a kapcsolatot, 
mindegyikük ARP-gyorstárolójában megtalálható a másik 
fél IP-címe és a hozzá ARP-vel , megtalált" MAC-address. 
Ezt az állapotot mutatja az első ábra. 





IP: 172.16.0 100 IP: 172.16.0 200 
MAC: AA-AA-AA-AA-AA-AA MAC: BB-BB-BB-BB-BB-BB 
ARP-cache ARP-cache 


172.16.0. 200 -: BB-BB-BB-BB-BB-BB ——— 172.16.0. 100 -: AA-AA-AA-AA-AA-AA 


H 


s—— ri 


A és B gép ARP-gyorstárolója normális 
kommunikáció estén 


Ha most a rossz szándékú támadó egy harmadik számító- 
gépről ügyesen elkészített ARP-üzeneteket dobál a háló- 
Zzatra (braodcast), rendesen össze tudja zavarni a már 
kommunikáló feleket. 

Célunk, hogy egy harmadik számítógép beilleszkedjen e 
kettő közé, vagyis az A gép H-t (Hacker) tekintse B-nek, és 
B szintén H-t higgye A-nak. Móricka elképzelése szerint 
elég, ha a két gyanútlan gép IP-címeit beállítjuk a harma- 
dik számítógépen. De ezt a jelenséget mindenki ismeri: IP- 
cím ütközés. Kész lebukás, ráadásul nem is célravezető, 
mert egy pillanatig sem hiszi egyetlen gép sem, hogy H va- 
lóban A. (Vagy B. Nézőpont kérdése.) 

A hiba oka, hogy normális esetben a Gratious ARP címzés- 
módja broadcast, pontosan azért, hogy mindenki meghall- 
ja. Csak úgy lehetne becsapni A-t és B-t, ha A becsapását 
nem hallaná B, míg B átveréséről nem értesülne A. Tehát 
broadcast helyett unicast címzéssel, csak az éppen 
célbavett áldozatnak kell eljuttatni az ARP-csomagot. Ilyet 
azonban kedvenc operációs rendszerünk önként nem fog 
tenni. De erőszakkal igen! 

A Network Monitor teljes verziójával tetszőleges Ethernet- 
csomag készíthető, sőt, a hálózatba küldhető. De még er- 
re sincs szükség, kész eszköz található e célra a 
http://vww.insecure.org címen. Nem árulom el a nevét, 
ennyire kész receptet nem akarok adni. Mindenesetre ké- 
pes arra, hogy így átírja A és B ARP cache-ét: 





A B 

IP: 172.16.0 100 IP: 172.16.0 200 
MAC: AA-AA-AA-AA-AA-AA MAC: BB-BB-BB-BB-BB-BB 
ARP-cache: ARP-cache: 

172.16.0. 200 -: HH-HH-HH-HH-HH-HH 172.16.0. 100 -2 HH-HH-HH-HH-HH-HH 
Gratious ARP: H Gratious ARP: 

172.16.0.200 - 172.16.0.100 

HH-HH-HH-HH-HH-HH ZEEZEZA HH-HH-HH-HH-HH-HH 


IP: mindegy 
MAC: HH-HH-HH-HH-HH-HH 


H meghamisította A és B ARP-gyorstáro- 
lójának tartalmát 


Ezzel megtörtént a lehetetlen: A minden B-nek szánt cso- 
mag Ethernet-fejlécébe címzettként H MAC-addressét írja 
be, így a switch az adatokat H-hoz továbbítja. Ott el lehet 
olvasni valamilyen monitorprogrammal, majd továbbkülde- 
ni most már B felé. A http://www.insecure.org-on olyan esz- 
közöket is találunk, amelyek erre az infrastruktúrára épülve 
magasszintű protokollok olvasgatását, sőt írását is lehető- 
vé teszik (SMB Session Hijacking). 
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Védekezés -IPRSec 
Biztosan nem írtam volna meg ilyen részletességgel ezt a 
támadástípust, ha nem létezne ellene védekezés. Az 
IPSec, vagyis az IP-csomagok titkosítása és digitális aláírá- 
sa tökéletes védelmet nyújt ez ellen a támadástípus ellen, 
noha az ARP-cache átirkálása továbbra is fennmarad, mint 
jelenség. De IPSec használatával már csak arra elég, hogy 
félrevigyen hálózati csomagokat, tehát Denial of Service tá- 
madásra továbbra is felhasználható. 
Az IPSec többféle üzemmódja közül nekünk az alábbiak 
tesznek jó szolgálatot: 

Wu 1IP-csomagok aláírása (Authentication Header, AH) 

mu Adatfolyam-titkosítás (Encapsulated Security Pay- 

load, ESP) 


Egy korábbi TechNetben már szóbakerült, hogy IPSec- 
csatorna nem építhető fel a kommunikáló felek (számítógé- 
pek) előzetes azonosítása nélkül. Azt is megírtam, hogy ez 
pontosan a Man-in-the-middle támadás miatt szükséges, 
mert az IPSec által használt kulcscsere-algoritmus, a Diffie- 
Hellman maga is érzékeny a középen álló csereberélőre. 
Három azonosítási mód közül választhatunk: 

u Kerberos. Ez csak azonos tartományon (vagy meg- 

hatalmazott tartományokon) belül működik 
mu X.509 tanúsítványok. Közös CA-tól kell származniuk 
mu Preshared key: jó előre leosztott titkos kulcsszó 


Ha kiválasztottuk a megfelelőt, már csak be kell kapcsol- 
nunk az IPSec-et. Kapunk is három gyári IPSec-házirendet, 
de nem javaslom, hogy vaktában bekapcsoljuk az egyiket. 
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I Console Root Name Descn 
§$ 1P secury Pokcies on Local Computer. [GZ cient (Respond Only) Communicate normally (unsecured), Use tb 
Ej secure Server (Regure Securty) For alIP traffic, always regure security us 
Ed server (Regvest Securty) For al IP traffic, always regyest security u 


Gyári, konyhakész IPSec-házirendek 








Egyfelől azért nem, mert veszélyes is lehet. Ha néhány gé- 
pen bekapcsoljuk Group Policyval a Secure Server opciót, 
más számítógépeken meg semmit, az előbbiek elveszítik 
az utóbbiakkal a kapcsolatot, mert nem állnak szóba titko- 
sítatlanul próbálkozókkal. Másfelől mert a gyári policyk 
mindegyike ágyúval lő a verébre, és a világ összes IP- 
címére ISAKMP/Oakley csomagot próbál küldeni, nem ma- 
rad veszteg, nem marad a belső hálózaton. Ez egy 
tűzfalgazda szemszögéből nézve nem valami kulturált vi- 
selkedés, és még jelentős sávszélesség-pazarlással is jár. 
Harmadrészt ha bátortalanul a Client only házirendet vá- 
lasztjuk, hamis biztonságérzetben ringatjuk magunkat: ez 
nem titkosít semmit, amíg más meg nem kéri erre. 
Mondjuk ki: az IPSecet azért nem használja senki, mert 
vagy eleve nem ismeri, ezért fél tőle, vagy már ismeri a 
gyári alapbeállításokat, ezért lemond róla. Ennek nem kel- 
lene így lennie! Az IPSec megismerhető, saját policy fara- 
gásával a bumfordisága orvosolható. Ez is témája az ötna- 
pos, 2277-es hivatalos Microsoft-tanfolyamnak. 
Főri MARCELL 
marcellféonetacademia. net 
MCT. MCSE. MCDBA. MZ/X 





Ott! 


Hivatalos Microsoft tanfolyamokra épülő, rugalmas beosztású, kedvezményes 
konstrukciójú és árú képzéssorozatok. Különböző segédanyagokat, vizsgafelkészí- 
tő anyagokat tartalmazó oktatási konstrukciók és csomagok. Kedvezményes lehe- 
tőségek további tanfo-lyamokra, vizsgákra és felkészítő anyagokra. 


Válassza ki az Önnek megfelelő 


minősítést és képzési konstrukciót! 


Microsoft rendszeradminisztrátor (MCSA) képzés 
A kisebb Windows Server 2003 alapú informatikai rendszereket és hálózatokat 
üzemeltetni kívánó szakemberek számára ajánljuk. 


Két tanfolyam (80 óra) - 249.000 Ft--ÁFÁ-tól 


Microsoft rendszermérnök (MCSE) képzés 

Nagy, összetett IT rendszereket és hálózatokat üzemeltető szakemberek képzése, 
akiknek feladatuk lesz Windows Server 2003 alapú hálózatok teljes körű admi- 
nisztrálása és támogatása, informatikai infrastruktúrák és folyamatok tervezése. 


Négy 4 1 tanfolyam (160 óra) - 499.000 Ft-ÁFÁ-tól 
Kezdési időpont: április 5. és május 10. 


A tanfolyamok mindegyikére beváltható a Microsoft 
frissítési garancia tanfolyambón (SA voucher) is. 


Valamennyi tanfolyam szakképzési hozzájárulásból 
elszámolható! 


A tanfolyamokkal és akciókkal kapcsolatos további tudnivalók weboldalunkon 
találhatók, vagy kérjük, keresse szervezőnket! 


Microsoft 


GOLD CERTIFIED 


Partner 





Tel.: 203-0304/3050 (Simon Fereni 
1115 Budapest, Etele út 68. 


